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1.  Introduction 


This  document  formally  describes  the  requirements  for  a  demonstration  of  a 
secure  electronic  registry  control  system  (Serous)  to  be  implemented  usine  the 
security  attributes  of  the  SI1ITE  secure  capability  computer  (1.2/3).  The 
formal  notation  used  in  this  specification  is  ’2’  .  which  has  been  developed  by 
the  Programming  Research  Group  at  Oxford  University  [*•]. 

5ercus  is  intended  to  control  the  access  to.  and  creation  of.  class^ied 
documents  and  files.  In  the  paper  world,  all  documents  and  files  are  centrally 
recorded  and  information  as  to  who  has  had  access  to  them  is  maintained. 
Sercus  will  enforce  similar  mechanisms.  In  addition  to  handling  documents  and 
files,  users  of  Sercus  will  be  able  to  send  simple  mail  messages. 

When  users  are  logged  on  to  Sercus  they  are  presented  with  a  d'srlc,-  the*, 
consists  of  a  set  of  windows,  fill  the  window  software  will  be  completely 
trustworthy .  but  may  be  used  to  invoke  untrusted  software.  While  untrusted 
software  is  active  in  a  window  the  classification  of  the  data  is  prcm,n,ently 
displayed.  Sercus  will  monitor  the  movement  of  objects  between  these  windows, 
and  correctly  maintain  the  classif ication  levels.  -  4 

The  specif  ication  of  Sercus  is  divided  into  two  distinct  parts.  The  first  pa^t 
specifies  the  underlying  components  of  the  system,  such  as  the  documents, 
users  and  displays,  and  defines  the  basic  operations  on  them.  The  second  part 
shows  how  these  components  are  combined  together  and  constraints  added  to  the 
basic  operations  to  create  a  system  that  is  both  functional  and  secure. 

This  specification  will  form  the  basis  of  an  investigation  into  techniques  f  o'" 
proving  conformance  between  high  level  specif  ication  and  code  level 
implementation.  This  is  required  to  achieve  the  highest  possible  levels  of 
design  assurance- 
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Part  1 


The  following  sections  describe  the  various  components  of  Sercus,  such 
documents*  files  and  users,  and  define  the  simple  operations  upon  them. 
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2.  General  Types 


[  CLASS  ] 

There  is  a  given  set  of  class  i  f  i  cat  i  ons.  These  are  used  for  classifying 
objects  and  giving  clearances  to  users. 

There  is  a  relationship*  2*  between  classifications  to  indicate  domination.  This 
will  be  needed  when  checking  whether  a  user  is  cleared  to  see  a  document.  For 
example*  a  user  cleared  to  'Secret'  will  be  able  to  read  a  'Restricted' 
document*  because  the  classification  Secret  dominates  Restricted.  However, 
users  cleared  to  Restricted  will  not  be  able  to  read  Secret  documents. 

|  _  2  _  :  par t i ai_araer (  CLASS  ) 

This  ordering  is  partial  because  not  all  classifications  are 
comparable.  For  example  'Secret  UK  Eyes  Only'  neither  dominates 
nor  is  dominated  by  'Secret  US  Eyes  Only'  . 

It  is  useful  to  define  a  classification  that  is  dominated  by  all  other  possible 
classifications- 


bottom  : 

CLASS 

b  class 

:  CLASS  •  class  2  bottom 

There  is  a  least  upper  bound  operator  between  two  classifications.  I  his  returns 
the  lowest  classification  which  dominates  both  of  them-  For  example*  a 
document  that  contains  both  Secret  Atomic  and  Secret  Nato  information  must  be 
classified  to  at  least  ‘Secret  Atomic  Nato'  . 


_  lub  _ 

:  (  CLASS 

*  CLASS  )  -  CLASS 

b  a*  b  : 

CLASS  . 

a 

lub  b  2  a 

a 

lub  b  2  b 

b 

1  :  CLASS 

1  1  2  a  a  1  2  b  • 

1  2  a 

lub  b 

Note  that  this  function  is  total.  This  implies  that  there  is  one 
classif ication  which  dominates  all  other  possible  classifications. 

An  operation  that  takes  a  set  of  classifications  and  returns  the  lowest 
classification  that  dominates  all  of  them,  is  also  defined- 

)  LUB_  :  P  CLASS  -  CLASS 


y  set  :  P  CLASS  . 
b  c  ;  set  • 

LUB  set  2  c 

b  1  :  CLASS  |  b  c  :  set  •  C  1  2  c  )  *  C  1  2  LUB  set  ) 


[  STR  ] 

There  is  a  given  set  of  character  strings.  These  are  intended  to  represent 
printed  messages  on  the  screen,  such  as  the  current  classification.  An 
operation  which  takes  a  classification  and  returns  the  string  representing  it  is 
defined. 


General  Types 
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|  show  _  :  CLASS  >-»  STR 

This  is  a  function  because  there  is  only  one  string  to  represent 
each  classification.  The  function  is  total  because  all 
classifications  must  be  representable/  and  one  to  one  because  all 
the  strings  must  be  unique. 

[  CAPABILITY  1 

There  is  a  given  set  of  capabilities  for  all  possible  objects.  A  capability  'S  a 
universal/  unforgable  name  for  an  object-  Capabilities  are  the  means  of 
refering  to  objects.  Each  capability  refers  to  only  one  object/  and  there  s 
only  one  capability  for  each  object. 

Capabilities  are  only  distinguishable  by  the  virtue  of  the  objects 
they  refer  to.  This  means  that  whenever  capabilities  are  copied  it 
is  impossible  to  tell  them  apart  as  they  will  refer  to  the  same 
object.  Hence-  the  restriction  that  there  is  a  single  capability  for 
each  object  in  Sercus-  and  consequently  capabilities  can  be  in  more 
than  one  place  at  a  time. 

[  TIME  ] 

Time  exists-  and  a  relationship  between  two  times  to  indicate  ’not  later  the'.'  is 
defined. 

|  :  total_order(  TIME  ) 

This  ordering  is  total  since  all  times  are  comparable. 

The  current  t'me  will  always  be  available  in  Sercus-  although  no  operations  to 
update  it  will  actually  be  defined. 

|  t i me_now  :  TIME 
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3.  Documents  and  Files 


3.  1  Introduction 

Sercus  is  intended  to  control  the  access  to.  and  creation  of.  classified 
documents  and  files,  and  to  model  some  of  the  mechanisms  in  use  in  the  paper 
world  that  do  this.  In  the  paper  world,  all  documents  are  centrally  recorded 
on  a  Classified  Document  Register  (cdr)  and  all  files  on  a  Filelist.  Documents 
can  be  uniquely  identified  by  their  cdr  number,  or  if  they  have  been  filed,  by  a 
file  number  and  enclosure  number.  The  cdr  also  records  the  people  who  have 
seen  the  document. 

For  the  purposes  of  specification  it  is  useful  to  partition  the  set  of  all 
possible  capabilities  into  three  sets. 


caps_for_docs  : 

P  CAPABILITY 

caps_f  or_f i les 

:  P  CAPABILITY 

caps_for_anon  : 

P  CAPABILITY 

<  caps_for_docs 

,  caps_for_f i les ,  caps_f or _anon  > 

partition  CAPABILITY 

This  means  that  when  creating  new  documents,  for  example,  it  will 
not  be  necessary  to  check  whether  the  capability  you  are  giving  the 
document  already  exists  as  a  file  or  other  capabi  lity . 

3 . 2  Documents  in  Sercus 

Documents  are  unalterable  objects  which  may  only  be  read.  They  have  a 
classification  bound  into  them  and  can  be  uniquely  identified  by  a  cdr  number. 
The  characters  that  make  up  the  text  of  a  document  are  uninteresting  as  far  as 
specification  at  this  level  is  concerned.  The  only  interesting  property  of  the 
contents  of  a  document  is  that  it  may  contain  capabilities  for  other  documents. 

Documents  do  not  move  about  the  system,  but  are  accessed  via 
capabilities.  Hence,  unlike  in  the  paper  world  the  cdr  will  not 
record  the  location  of  a  document,  but  will  record  which  users  have 
opened  the  document  (note  that  simple  possession  of  a  capability 
does  not  automatically  allow  access  and  consequently  it  is  not 
useful  to  record  this  fact).  This  mechanism  will  be  added  at  a 
later  date,  see  journalling  in  section  9.  1  and  10. 

[  CDR.NUn  ] 

There  is  a  given  set  of  cdr  numbers  that  will  be  used  to  uniquely  identify  the 
documents-  Cdr  numbers  are  ordered,  in  the  paper  world  on  date  of  creation, 
and  an  operation  to  discover  this  order  is  defined- 

I  ■■  total_order(  CDR_NUH  ) 

This  ordering  is  total  because  all  cdr  numbers  are  comparable. 


Documents  and  Files 
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DOCUMENT  _ 

class i f i cat i on  :  CLASS 
contents  :  P  CAPABILITY 
cdr_number  :  CDR_NUM 


contents  £  caps_f or_docs  Cl) 


(1)  Documents  can  only  contain  capabilities  for  other  documents. 

A  mapping  between  document  capabilities  and  their  associated  documents  is 
required.  Only  some  of  the  total  set  of  capabilities  for  documents  refer  to 
existing  documents/  as  other  capabilities  will  be  required  whenever  ne„ 
documents  are  created. 


_ THE_D0C5 


wh 

i ch_doc  :  CAPABILITY  m  DOCUMENT 

l  1  ) 

do 

m  which_doc  £  oaps_for _docs 

u 

c  :  dom  which_doc  • 

which_doc(  c  )• contents  £  dom  which_doc 

(2  ' 

y 

i ,  j  :  dom  which_doc  • 

which_doc(  i  ).cdr_number  =  which_doc(j  ).cdr_number  *-* 

=  j  ( 3  ) 

The  which_doc  function  maps  the  document  capabilities  to  their  documents-  The 
domain  of  this  function  is  the  set  of  all  the  document  capabilities  so  f  a- 
created.  Hence  the  range  is  the  set  of  all  the  documents  created  so  fa--. 


(1)  This  is  a  function  because  c?P3b:l'he?  ran  only  re^er  to  one 
document.  The  function  is  one  to  one  because  there  'S  only  one 
capability  for  each  document#  and  partial  because  not  all  the 
possible  documents  have  yet  been  created. 

(2)  All  the  documents  in  Sercus  may  only  contain  capabilities  for  other 
documents  that  exist. 

(3)  Documents  are  uniquely  identifiable  by  their  cdr  number. 

ATHE_D0CS  s  [  THEJDDCS';  THE_D0CS  ] 

ETHE_D0C5  fi  [  ATHE_D0CS  |  0THE_DOC5’  =  eTHE_DDES  1 
3-3.  Files  m  5ercus 

Files  in  Sercus  are  not  necessary  for  naming  or  accessing  documents-  They  a'e 
simply  a  conviement  grouping  of  document  capabilities.  In  the  paper  world  filed 
documents  can  be  identified  by  a  file  and  enclosure  number.  In  order  to  be  able 
to  do  this  in  Sercus#  it  is  necessary  to  insist  that  the  document  capabilities 
may  be  on  at  most  one  file. 

Note  that  although  documents  can  only  be  on  a  single  file#  they  _cn 
contain  capabilities  for  documents  on  other  files. 

[  FTITLE  1 

All  files  will  have  a  title#  which  is  taken  from  the  given  set#  and  is  itself 
classified.  Files  also  have  an  overall  classification#  which  must  dominate  the 
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Documents  and  Files 


title  classification/  and  the  classification  of  all  the  documents  they  contain. 
However/  the  overall  classification  is  not  necessarily  the  least  upper  bound  of 
the  title  classifications  and  the  document  classifications/  but  could  be 
significantly  greater.  For  example/  a  Secret  file  may  only  contain  Confidential 
documents.  Documents  on  a  file  are  ordered  by  enclosure  numbers,  which  are 
taken  from  the  set  of  natural  numbers. 

FILE _ _ _ , 

title  :  FTITLE 

title_class>  overal l_class  :  CLASS 
docs  :  seq  CAPABILITY 


ran  docs  £  caps_for _docs  (1) 

overal l_class  2  title_class  (2) 

d  i/j  :  dom  docs  •  docs(  i  )  =  docs(  j  )  **  i  =  j  (3) 


Cl)  Only  capabilities  for  documents  may  be  put  on  a  file- 

Note  that  although  this  specifies  that  tiles  can  contain  only 
document  capabilities,  it  is  only  later,  see  section  3.4,  the  Filing 
System,  that  it  can  be  insisted  that  these  documents  actually 
exist . 

(2)  The  overall  classification  of  a  file  must  dominate  the  title 
classification. 

Note  that  the  fact  that  the  overall  classification  must  also 
dominate  the  classification  of  all  the  documents  on  the  file  cannot 
be  specified  until  later  (section  3-4). 

(3)  Documents  cannot  be  put  on  a  file  more  than  once. 

Note  that  the  position  in  the  sequence  of  filed  capabilities 
represents  the  enclosure  number  of  the  document. 

As  for  documents,  a  mapping  between  the  file  capabilities  and  files  is  required. 

_  THE_FILES _ _ 


wh i ch_f 

ile  :  CAPABILITY  m 

FILE 

dom  wh i 

ch_f i le  £  caps_for_ 

.files 

y  file 

:  ran  which_file  • 

file. docs  *  <  > 

(1  ) 

y  i  .  j  : 

ran  which  file  • 

ran 

i . docs  n  ran  j.docs  *  O  ++  i  =  j 

(2  i 

i. title  =  j. title  i 

=  J 

(3  ) 

- -  1 

The  which_file  function  maps  the  file  capabilities  to  their  particular  files.  The 
domain  of  this  function  is  the  set  of  all  the  capabilities  for  files  so  far 
created-  Hence  the  range  is  the  set  of  all  the  files  created  so  far. 

(1)  Files  cannot  be  empty. 

(2)  Documents  can  only  be  on  a  single  file. 
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(3;  All  files  can  be  umqely  identified  by  their  title. 

Hence  a  document  can  be  uniquely  identified  by  supplying  a  file  title  and  a- 
enclosure  number. 

ATHE_F1LES  £  [  THE_FILE5’;  THE_FILES  ] 

ETHE.FILES  £  [  ATHE_FILES  I  eTHE_FILE5’  =  eTHE_FlLE5  ] 

3  -  4 .  The  Filing  System 

The  filing  system  for  5ercus  is  simply  the  files  and  documents  so  far  createc, 
together  with  the  constraint  that  the  files  can  only  contain  capabilities  f C' 
documents  that  exist. 


(1)  Files  can  only  contain  capabilities  for  known  documents. 


(Z)  The  overall  classification  of  a  file  dominates  the  classifications  of 
all  the  documents  it  contains. 

HFILlNG_SYSTEn  £  t  FILING.SYSTETV  ;  FILlNG_SYS7En  1 

EFIL ING_5YSTEP1  £  [  fiFIUNG_SYSTEn  | 

6FILlNG_SYSTEn'  =  eFILlNG_5Y5TEf1  ] 

It  is  important  to  note  that,  in  this  specification,  operations  on  documents  must 
be  performed  via  the  filing  system.  This  is  because  files  can  alter  as  a  sde 
effect  of  the  Simple  operations  on  documents.  For  example,  chang  ng  tue 
classification  of  a  document  could  alter  the  classification  of  any  file  that 
contains  a  capability  for  the  document. 

3-5  Destroying  Objects 

No  operations  to  explicitly  destroy  objects  m  Sercus  are  defined-  This  s 
because  unlike  in  the  paper  world,  documents  and  files  may  be  accessed 
more  than  one  user  at  a  time-  Revoking  access  to,  or  destroying,  the  objects 
then  proves  very  difficult,  as  users  could  still  possess  capabilities  fc- 
objects  that  no  longer  exist.  As  far  as  this  specifiction  is  concerned,  the 
capabilities  could  even  potentially  have  been  reused  for  other  objects.  An* 
journalled  information  about  the  object  could  also  have  been  lost,  and  this  is 
undesirable  in  a  secure  system.  However,  documents  and  files  could  be 
effectively  removed  by  regrading  them  so  that  no  users  are  cleared  to  see 
them  any  more . 
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3 . 6  ■  Filing  System  Operations 


This  section  describes  the  underlying  filing  system  operations-  These  will  be 
further  defined  as  the  specification  proceeds  (refer  to  part  2). 

3-6-1  create  a  document 


Creating  a  document  involves  providing  some  contents  and  a  classification.  This 
operation  results  in  a  new  document  and  capability  which  are  added  to  the 
which_doc  function.  Hence,  the  operation  involves  a  change  to  the  existing 
documents,  but  not  to  any  files-  In  the  paper  world  all  documents  are  recorded 
on  the  cdr  and  on  creation  will  be  given  a  cdr  number  to  reference  them.  Hence, 
this  operation  also  results  in  the  new  cdr  number. 

_ create  document,.  _ _ 

AFILING_SYSTEH 

ETHE_FILES 

class i f i cat i on7  :  CLASS 
contents7  :  P  CAPABILITY 

new_cap !  :  CAPABILITY 
new_doc !  :  DOCUhENT 
cdr_num!  :  CDR  NUH 


contents7  £  dom  which_doc 
new_cap!  e  dom  which_doc 
new_doc!  t  ran  which_doc 

new_doc ! . class i f i cat i on  =  classification7 
new_doc !. contents  =  contents7 
new_doc ! ■ cdr_number  =  cdr_num! 

B  d  :  ran  which_doc  •  ( 4  ) 

cdr _n urn !  *  d-cdr_number 
cdr_num!  2  d-cdr_number 

which_doc'  =  which_doc  U  f  new_cap!  «  new_doc!  >  (5) 


(1  ) 
(2) 
(3  ) 


(1)  The  conte  ts  of  a  new  document  can  only  be  capabilities  to  already 
known  documents. 

(28.3)  The  new  document  and  its  capability  did  not  exist  before  the 
operation . 

This  means  that  the  capability  for  the  new  document  cannot  be  part 
of  the  supplied  contents.  Hence,  since  document  contents  are 
unalterable,  no  document  can  refer  to  itself- 

(4)  The  new  document  has  the  supplied  classification  and  contents  and 
is  assigned  a  cdr  number.  This  cdr  number  is  not  one  of  those 
belonging  to  already  existing  documents,  and  is  'greater  than’  all 
the  exiting  numbers.  However  the  new  number  is  not  necessarily  the 
next  in  the  sequence,  and  it  is  possible  that  there  are  'holes'  in 
the  cdr. 

(5)  After  the  operation,  the  new  capability  will  be  mapped  to  the  new 
document  by  the  which_doc  function.  All  other  mappings  are 
unchanged. 
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3-6.2  read  a  document 


f 

a 


f 


h 


! 


i 


Opening  a  document  does  not  alter  existing  documents  or  files-  A  capability 
for  a  document  is  supplied/  and  the  operation  results  in  the  set  of  c spec  1  t  es 
that  make  up  its  contents- 


_ r ead_document 


EFILING_ 

SYSTEM 

doc_cap7 

:  CAPABILITY 

conten  ts 

!  :  P  CAPABILITY 

contents 

!  =  which_dDc(  doc_cap7  ). contents 

• 

Note  that  at  this  level  of  specification  there  is  no  notion  of 
checking  clearances-  This  cannot  be  added  until  after  the  users 
have  been  specified  (section  14). 

3-6-3  finding  documents 


Users  will  be  able  to  ask  for  documents  b;  their  cdr  number  or  file  title  and 
enclosure  number.  This  operation  lists  all  the  documents  known  to  Sercus  by 
their  cdr  number,  but  does  not  alter  any  documents  or  files- 


_ 1 i st  _cdr 


b  AS  X  C  _0  p 


3F I LIND_5Y5T£n 


cdr !  :  seq  CDR_NUM 


ran  cdr!  =  {  d  :  ran  which_doc  •  d-cdr_number  >  (1) 

W  i,  j  :  dom  cdr!  |  i  £  j  .  cdr ! (  i  )  £  cdr ! (  j  )  (2) 

-  -  I 

(1&2)  Listing  the  cdr  results  in  a  sequence  of  all  the  cdr  numbers  for 
existing  documents.  This  sequence  is  ordered. 

The  following  operation  looks  up  a  cdr  number  and  returns  the  associates 
document  capability.  The  filng  system  is  unaffected. 


f i nd_document 


r 

b  AS  iC.OP 

' 

efiling_system 

cdr_num':’  : 

CDR_NUn 

doc_cap!  : 

CAPABILITY 

cdr _num7  e 
wh i ch_doc ( 

d  :  ran  which_doc  • 
doc_cap!  ).cdr_number 

d- cdr_number  > 

=  cdr_num7 

(1  ) 

1 

(1)  The  cdr  number  must  be  assigned  to  an  existing  document,  and  the 
Lorrect  document  capability  is  supplied- 
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This  operation  takes  a  file  title  and  enclosure  number  and  returns  the  required 
document  capability.  The  filing  system  is  unaffected. 


This  operation  lists  the  contents  of  a  file.  The  filing  system  is  unaffected. 


_ f i le.contents 


EFILING 

b**iC_OP  - 

.SYSTEM 

t i t le7 

FTITLE 

caps !  : 

P  CAPABILITY 

caps ! 
where 
file 

=  f i le. docs 

:  ran  which.file 

title  =  tit le7 

_ i 

Note  that  further  contramts  will  be  added  in  part  2  to  ensure  that 
the  user  performing  this  operation  is  cleared  to  see  the  file 
contents. 

3-6.4  add  document  to  a  file 

Adding  a  document  to  an  existing  file  involves  supplying  the  file  and  the 
document  capability.  The  enclosure  number  of  the  document  on  the  file  is 
returned.  The  overall  file  classification  may  have  to  increase,  in  order  to 
dominate  the  classification  of  the  new  document.  No  other  files  or  any  of  the 
documents  are  changed  by  this  operation. 


Documents  and  Files 
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_ _ add  doc  to  f i lev 

—  —  bit iC.DP 


/\FILING_SYSTEf1 

HTHEJDOCS 

f i le_cap7  :  CAPABILITY 
doc_cap7  :  CAPABILITY 

file!  :  FILE 
enc!  :  N 


file_cap7  e  dom  which_file 

doc_cap7  e  dom  which_doc  11  1 

doc_cap7  i  U-C  file  s  ran  which_file  •  ran  file,  docs  >  1 2  i 

file!  e  ran  which_file 

file!. docs  =  which__file(  file_cap7  l.docs  "  (  doc_cap7  ) 
file '.-title  =  which_file(  file_cap7  ).  title 
f i le ! . t i t le_class  -  which_file(  f i le_cap7  ). t i t le_class 
f i le ! . over al l_class  =  which_file(  file_cap7  ). overal l_class 

lub 

which_doc(  doc_cap7  ). class i f i cat  i  on 
wh i ch_f ile’  =  wh  i ch_f i le  e  {  f i le_cap7  «  f i le !  >  (31 

enc !  =  »  file!. docs 


(18,2)  The  capability  supplied  must  be  for  an  existing  document  that  is  not 
already  on  any  file. 

(3)  After  the  operation,  the  supplied  capability  now  refers  to  a  new 
file  (replacing  the  old  file).  This  file  is  a  copy  of  the  original  file 
except  that  the  new  document  is  added  to  it  and  the  overall 
classification  dominates  the  new  document's  classification.  No 
other  files  are  changed. 

3-  6. 5  create  a  file 


To  create  a  file,  a  document,  file  title  and  title  classification  must  be 
supplied.  The  overall  classification  is  the  document  classification,  which  must 
of  course  dominate  the  title  classification.  The  document  cannot  already  be  on 
any  file.  The  which_file  function  will  now  also  map  the  file  capability  to  the  ne~ 
file-  The  existing  documents  are  not  changed  and  nor  are  any  previous  files- 
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AFILING_SYSTEM 

HTHE_DOCS 

doc_cap7  :  CAPABILITY 
title7  :  FTITLE 
title_class7  :  CLASS 

new  file!  :  FILE 
new_cap !  :  CAPABILITY 


doc_cap?  e  dom  which_doc  (1) 
doc_cap7  g  IK  file  :  ran  which_file  .  ran  file. docs  >  (2) 
title7  g  f  file  :  ran  which_file  •  file. title  >  (3) 
which_doc(  doc_cap7  ). class i f i cat . on  2  title_class7  (4) 

new_cap!  g  dom  which_file  (5) 
new_file!  g  ran  which  file  (6) 


new_f i le ! . docs  =  <  doc_cap7  > 
new_f i le ! . t i t le  =  title? 

new_f i le ! . overal l_class  =  which_doc(  doc_cap7  ). class i f i cat i on 
new_f i le ! . t i t le_class  =  title_class7 

which_file'  =  which_file  U  {  new_cap!  «  new_file!  >  (7) 


(18.2)  The  capability  supplied  must  be  for  an  existing  document  that  is  not 
already  on  any  file. 

(3)  The  supplied  title  must  be  unique. 

(4)  The  classification  of  the  document  to  be  put  on  the  file  (this  will 
be  the  overall  file  classification)  must  dominate  the  given  title 
classification. 

(586)  A  new  file  capability  and  file  are  created*  ie  they  did  not  exist 
before  the  operation. 

(7)  After  the  operation*  the  which_file  function  will  map  the  new 
capability  to  the  new  file.  No  other  files  are  changed. 

3-6.6  regrade  file 

Both  the  title  and  overall  classification  of  a  file  may  be  regraded.  However, 
the  overall  classification  of  a  file  cannot  be  regraded  lower  than  the  title 
classification.  In  such  cases*  the  title  classification  would  have  to  be 
regraded  first- 

Changing  the  classification  of  a  file  involves  supplying  the  file  and  a  new 
classification.  The  following  schemas  specify  regrading  the  title  and  the 
overall  classifications  of  a  file. 
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_regrade  file  title. 

—  —  bis ic_op 

AFILING_SYSTEf1 

~THE_DOCS 

f i le_cap7  :  CAPABILITY 
title_class7  :  CLA5S 

file!  :  FILE 


f i 1 e _ cap7  e  dom  which_file 

file!  t  ran  which_file 

f i le! -t itle_class  =  title_class7 
file! -docs  =  which_file(  f i le_cap7  l.docs 
file!. title  =  which_file(  f i le_cap7  ). title 
f i le ! • overall_class  =  which_file(  f i le_cap7  ). overal l_cl ass 

which_file'  =  which_file  e  {  f i le_cap7  «  file!  T  (3) 


( 1  1 
(2  ) 


(1)  The  file  to  be  regraded  must  be  known  to  the  system. 

(2)  A  new  file  is  created.  ie  one  not  known  before  the  operation.  Th'S  is 
a  copy  of  the  file  to  be  regraded,  except  that  it  has  the  new  title 
classif  ication . 

Note  that  the  title  classification  cannot  be  greater  than  the 
overall  classification . 

(3)  The  original  file  is  replaced  by  the  new  file  and  no  other  files  are 
changed. 

_ regr ade_f  i  le  _ _ _ _ _ _ 

AFILING_SYSTEn 

ATHE_DDCS 

f i le_cap7  :  CAPABILITY 
overal l_class7  :  CLA5S 

file!  :  FILE 


file_cap7  e  dom  which_file 
file!  ran  which_file 

f i le !. overal l_class  =  overall_class7 
file!. docs  =  which_file(  f i le_cap7  )-docs 
file!. title  =  which_file(  file_cap7  1-title 
f i le ! ■ t i t le_class  =  which_file(  f i le_cap7  ). t i tle_class 

which_file’  =  which_file  e  f  i  le_cap7  «  file1  >  [3  1 


( 1  ) 

(2  1 


(1)  The  file  to  be  regraded  must  be  known  to  the  system. 

(2)  A  new  file  is  created,  le  one  not  known  before  the  operation.  This  is 
a  copy  of  the  file  to  be  regraded,  except  that  it  has  the  new 
overall  classification. 

Note  that  the  Filing  System  schemas  insist  that  the  overall 
classification  must  dominate  the  classification  of  all  the  documents 
on  the  file,  and  consequently  a  file  cannot  be  regraded  lower  than 
the  least  upper  bound  of  all  the  documents  classifications . 
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(3)  The  original  file  is  replaced  by  the  new  file  and  no  other  files  are 
changed. 

Simply  regrading  a  file  does  not  alter  any  documents.  However,  regrading  a 
document  may  result  in  a  file  classif cation  being  regraded,  hence  splitting  the 
regrade_file  schema  into  two  parts. 

regrade_f i le,  .  A  regrade_file  a  3THE_D0CS 

3.G.7  regrade  document 

Regrading  a  document  involves  supplying  a  document  and  a  new  classification.  If 
this  document  is  on  a  file,  the  overall  classification  of  the  file  may  have  to 
change  as  a  consequence. 

The  operation  is  split  into  two  parts.  The  first  regrade  schema  is  relevent  when 
the  document  in  question  has  not  been  filed,  and  the  second  when  it  has. 

This  regrade  operation  simply  changes  the  classification  of  a  document  that  is 
not  on  any  file. 

_ regrade_unf  i  led_document  . . , 

afiling_system 

3THE_FILES 

doc_cap7  :  CAPABILITY 
class7  :  CLASS 

doc!  :  DOCUMENT 


doc_cap7  €  dom  which_doc  (1) 

doc_cap7  4  U-C  file  :  ran  which_file  •  ran  file. docs  >  (2) 

doc !. contents  =  which_doc(  doc_cap?  ). contents 

doc  !  .  cdr_number  =  which_doc(  doc_cap7  ).  cdr_number 

doc ! . class i f i cat i on  =  class7  (3) 

which„doc’  =  which_doc  •  -C  doc_cap?  ►*  doc!  >  (f) 

- 1 


( 1  &.Z )  The  document  to  be  regraded  must  be  known,  and  is  not  on  any  file. 

(3)  A  new  document  is  created  which  is  given  identical  contents  and  cdr 
number,  but  has  the  new  classification. 

(“U  After  the  operation,  the  which_doc  function  maps  the  document 
capability  to  the  new  document.  No  other  documents  are  changed. 

This  following  schema  defines  the  operation  to  change  the  classification  of  a 
filed  document  and  indicates  which  file  the  document  is  on.  However,  it  does  not 
alter  the  overall  classification  of  the  file. 
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_ re9rade_f i led_document 

AFILING_5YSTEM 

doc_cap7  :  CAPABILITY 
class7  :  CLASS 

file_cap7  :  CAPABILITY 

doc  I  :  DOCUMENT 


doc_cap7  £  dom  which_doc  (1) 

doc_cap7  e  IK  file  :  ran  which_file  •  ran  file -docs  >  (2) 

doc!  g  ran  which_doc  (3) 

doc !. contents  =  which_doc(  doc_cap7  ). contents 
doc ! . cdr _number  =  which_doc(  doc_cap7  ).cdr_number 
doc !. class i f i cat i on  =  class? 

which_doc’  =  which_doc  e  -C  doc_cap7  ►»  doc!  3-  (4) 

doc_cap7  e  ran  (  which_file(  f i le_cap7  ).docs  )  (5) 


C 1 8. Z D  The  document  to  be  regraded  must  be  known,  and  must  be  on  a  file. 

(3)  A  new  document  is  created  which  is  given  identical  contents  and  cdr 
number,  but  has  the  new  classification. 

(4)  After  the  operation,  the  wh>ch_doc  function  maps  the  document 
capability  to  the  new  document.  No  other  documents  are  changed- 

(5)  The  file  capability  refers  to  the  particular  file  that  the  document 
is  on. 

This  schema  specifies  both  regrading  a  filed  document  and  the  file  it  is  on. 

rregrade_doc_and_f  i  le  _ , 

regrade_f i led_document 
regr ade_f i le 


o veral l_class7  =  which_file(  file_cap7  ). overal l_class 

lub 

class7  ( 1  ) 


(1)  The  new  overall  classification  of  the  file  will  be  the  least  upper 
bound  of  its  original  classification  and  the  new  document 
classification. 

The  complete  regrade  operation  is  either  the  simple  regrade  if  the  document  is 
not  on  a  file,  or  regrading  both  the  document  and  the  file  it  is  on. 

regrade  document.  £  regrade  doc_and  f i le 

v  regrade _ unf i led _ document 
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4.  Other  Objects 


Capabilities  are  not  restricted  to  refer  to  only  documents  and  files.  It  is 
possible  for  anonymous  objects  to  exist  about  which  the  system  knows  very 
little,  except  their  contents.  The  only  interesting  contents  of  an  anonymous 
object  is  the  set  of  capabilities  it  contains. 

These  anonymous  objects  could  for  example  contain  the  characters  for  making 
up  the  non  capability  contents  of  a  document  that  would  exist  in  a  real  system. 

ANON _ , 

contents  :  P  CAPABILITY 

_ i 

As  for  documents  and  files,  a  function  to  map  anonymous  capabilities  to  their 
associated  object  is  required. 

THE_AN0NS _ , 

which_anon  :  CAPABILITY  >**  ANON 


dom  which_anon  c  caps_f or_anon 


Similarly  the  domain  of  this  function  gives  the  set  of  all  existing  capabilities 
for  unknown  objects,  and  the  range  gives  all  the  existing  unknowns. 

ATHE_ANQNS  &  [  THE_AN0NS ’  ;  THE_AN0NS  1 

-THE_AN0NS  fi  t  ATHE_ANONS  |  0THE_ANONS’  =  eTHE.ANONS  ] 

The  contents  information  about  anonymous  objects  will  be  required 
later  when  these  objects  are  copied  and  stored. 

The  most  useful  operation  on  an  anonymous  object  is  to  make  a  copy  of  it. 


ATHE_ANONS 

-  ■  ^ 

original7,  copy!  : 
new_anon !  :  ANON 

CAPABILITY 

copy!  ^  dom  which_anon 
new_anon !  £  ran  which_anon 

new_anon !. contents  =  which_anon(  original7  ). 

contents 

(1  ) 

(2  ) 

which_anon’  =  which 

_anon  U  -C  copy!  ~  new_anon 

!  > 

» 

(18.2)  A  completely  new  capability  and  object  are  created. 
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5.  Displays 


5.  1  Introduction 

A  display  in  Sercus  Mill  consist  of  a  set  of  windows.  Some  of  the  windows  w  11  be 
running  untrusted  software,  although  this  will  be  monitored  by  the  window 
software,  which  is  trusted.  Windows  will  have  a  set  of  capabilities  that  a^e 
available  to  them.  The  display  will  contain  a  visible  representation  of  some  of 
these  capabilities.  Windows  that  are  monitoring  untrusted  software  will  have  the 
correct  classification  of  the  information  in  the  window  displayed  at  all  times. 
The  windows  that  are  not  running  any  untrusted  software  will  form  the  trusted 
path.  Certain  security  critical  operations  will  only  be  executed  if  they  have 
been  invoked  from  the  trusted  path  [51. 


The  set  of  all  possible  capabilities  can  be  partitioned  into  two  sets.  Trustee 
capabilities  are  associated  with  objects  that  can  be  trusted  to  maintain  the 
own  classification.  The  untrusted  capabilities  need  to  be  supervised. 

trusted_caps  :  IP  CAPABILITY 
untr usted_caps  :  P  CAPABILITY 


<  trusted_caps .  untr usted_caps  >  partition  CAPABILITY 


5 • 2  High  Water  Harks  and  Related  Groups 

Some  of  the  objects  in  Sercus.  such  as  files  and  documents,  have  them 
classification  bound  into  them,  and  are  trusted  to  maintain  it  correctly.  Other 
objects  are  not  classified  as  such.  However,  a  mechanism  is  needed  to  monitor 
the  classification  of  information  these  untrusted  objects  have  access  to.  Thus 
is  done  by  means  of  high  water  mark  classifications. 

Whenever  untrusted  software  is  accessing  objects  that  do  not  protect  them  own 
classification,  the  worst  case  situation  must  be  anticipated,  and  it  is  assumed 
that  all  these  objects  have  access  to  all  the  information  available  to  the 
software.  Whenever  one  of  the  objects  in  such  a  related  set  has  its 
classification  increased,  perhaps  by  opening  a  document,  all  the  other  objects 
are  assumed  to  have  access  to  the  same  information,  and  must  be  classified 
accordingly.  These  relationships  are  monitored  by  having  related  groups  cf 
objects  and  a  high  water  mark  classification  associated  with  each  group. 

[  GROUP  1 

Group  objects  are  the  mechanism  for  indicating  the  relationships  between 
untrusted  capabilities.  Untrusted  capabilities  can  be  associated  with  a  grouc 
object  taken  from  the  given  set.  and  will  be  assumed  to  be  related  if  they 
refer  to  the  same  group  object.  Capabilities  can  only  belong  to  a  single  related 
set.  and  hence  can  only  refer  to  a  maximum  of  one  group  object-  Each  group 
object  has  a  high  water  mark  classification  associated  with  it. 
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D i splays 


Restr i cted 


Restr i cted 


Figure  Is  As  far  as  Sercus  can  tell.  the  objects  in  each  circle 
are  related,  and  the  capabilities  for  these  objects  will 
all  be  associated  to  the  same  group  object.  The  group 
objects  have  the  high  water  mark  classification 
associated  with  them. 


_ HIGH_UIATER  J1ARKS 


which_group  :  CAPABILITY  -h,  GROUP  (1) 

hwm_class  :  GROUP  ■**  CLASS  (2) 

dom  which_group  c  untr usted_caps  (3) 

ran  which_group  C  dom  hwm_class  (40 

_ I 


(1)  Capabilities  are  related  if  they  refer  to  the  same  group.  This  is  a 
function  because  each  capability  can  only  belong  to  a  single  related 
group,  and  partial  because  not  all  capabilities  necessarily  belong 
to  a  group. 

(23  The  relationship  between  groups  and  classifications  is  a  function 
because  each  group  has  a  single  classification  associated  with  it. 
This  function  is  partial  because  it  will  be  necessary  to  create  new 
groups.  Related  sets  could  have  the  same  classification,  and  hence 
the  function  is  many  to  one.  The  domain  of  this  function  is  all  the 
group  objects  that  have  been  created  so  far. 

Note  that  not  all  the  existing  group  objects  necessarily  have  any 
capabilities  associated  with  them. 

(3)  Only  untrusted  capabilities  belong  to  groups. 

(4)  All  known  groups  will  have  a  classification  associated  with  them, 
regardless  of  whether  any  capabilities  are  in  the  group  or  not. 


AHIGH_WATER_f1ARK5  St  [  HIGHJdATERJIARKS’  ;  HIGH_WATER_f1ARK5  5 

EHIGHJJATERJIARKS  £  t  flHIGHJJATERJIARKS 

|  eHIGHJJATERJIARKS ’  =  eHIGHJJATERJIARKS  3 
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5-3  Windows  in  Sercus 


A  window  is  modelled  as  the  set  of  capabilities  that  are  available  to  it.  Tre 
characters  on  the  screen  are  uninterestms  as  far  as  this  specif icat'cn  is 
concerned  and  are  not  specified. 

WINDOW  _ , 

available  :  P  CAPABILITY 


[  WID  ] 

Windows  need  to  be  distinguishable  even  if  they  contain  identical  sets  o* 
capabilities.  In  order  to  be  able  to  do  this,  windows  have  a  unique  ident.f'e" 
associated  with  them,  taken  from  the  given  set. 

THEJ4IND0US  _ , 

which_window  :  WID  -*♦  WINDOW  (1  ) 


The  domain  of  the  which_window  function  gives  the  set  of  all  window  identifies 
that  are  valid,  and  the  range  all  the  windows  that  exist. 

(13  This  is  a  function  because  window  identifiers  can  only  refer  to  one 
window.  The  function  is  partial  because  not  all  the  possible  windows 
have  yet  been  created,  and  many  to  one  because  two  separate 
windows  can  contain  the  same  set  of  capabilities. 

ATHE_WINDOWS  £  E  THE .WINDOWS'  ;  THE .WINDOWS  ] 

HTHE.WINDOWS  £  [  ATHE.WINDOWS  I  eTHE.WINDOWS'  =  eTHE.WINDOWS  ) 

5  ■  4  Untrusted  Software 

Untrusted  software  has  a  set  of  capabilities  that  it  can  manipulate.  All 
untrusted  software  will  be  monitored  by  a  window  and  some  of  the  capebiLt  es 
that  the  untrusted  software  is  manipulating  will  also  be  known  to  this  window. 
Since  it  must  be  assumed  that  all  untrusted  capabilities  available  to  so^twa^e 
are  related,  the  monitoring  window  will  maintain  a  related  group  and  high  water 
mark  classification  for  all  those  that  it  is  aware  of.  This  classification  will  be 
displayed  in  the  window. 

In  all  the  following  diagrams  objects  in  the  clear  circles  could  be 
related  and  will  all  refer  to  the  same  group  object.  For  clarity, 
these  group  objects  have  been  omitted  from  the  diagrams.  Each 
related  group  has  a  high  water  mark  classification  associated  with 
it.  The  thicker  edged  squares  are  the  windows  and  the  other 
squares  the  untrusted  programs-  All  the  capabilities  in  each  square 
are  those  that  are  available  to  it.  Any  capabilities  in  the  overlap 
are  those  that  the  untrusted  software  is  manipulating  that  the 
window  software  is  aware  of. 
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Figure  2:  Window  not  running  any  untrusted  software. 


_ UNTRUSTED 


us  i  ng 

:  P  CAPABILITY 

mon i tor i ng  :  UID 

known 

:  P  CAPABILITY 

(1  ) 

group 

;  GROUP 

(2) 

class 

:  5TP 

(3  ) 

known 

£  using  D  untrusted_caps 

(4  ) 

-1 

(18.4)  All  untrusted  software  is  monitored  by  a  window.  A  subset  of  the 
capabilities  that  the  untrusted  software  is  using  will  be  untrusted 
capabilities  that  are  known  to  the  monitoring  window. 

(283)  Untrusted  software  will  also  have  a  related  group  of  capabilities 
associated  with  it  and  the  classification  for  this  group  will  be 
displayed. 

All  the  known  capabilities  in  the  untrusted  software  will  be  assumed 
to  be  related  and  so  will  all  belong  to  the  same  group.  The 
monitoring  window  will  maintain  the  group  and  high  water  mark 


D i splays 


22 


1 


classification  for  this  set ,  which  may  be  empty.  This  will  be  folly 
specified  in  the  followiing  section. 

5 . 5  The  Display 

ft  display  consists  of  windows  and  untrusted  software/  together  with  the  hg’- 
water  marks  and  related  groups  information. 

DISPLAY  _ , 

HIGH_WATER_MARKS 

THEJ4IND0UIS 

w  i  ndows  :  P  WlD 
programs  :  P  UNTRUSTED 


windows  C  dom  which_window 

{  p  :  programs  •  p.n'd  >  c  windows  (1  ) 

b  p,  q  :  programs  •  p • men i t or i ng  =  q. monitoring  <=»  p  =  q  (Z> 
b  p  :  programs  • 

p. known  =  fK  p. using,  untr usted_caps . 

wh i ch _ w i ndow(  p. monitoring  ). available  >  ( 3 J 

b  c  :  p. known  •  whichji-Qupf  c  )  =  P- group  (4  ) 

P-class  =  show  hwm_class(  p. group  1  (S'1 

b  w  :  w i ndows  • 

wh i ch _ w i n do w (  w  ). available  0  untr usted_caps 

£  dom  which_group  (S' 


(1)  The  programs  in  the  display  are  monitored  by  windows  in  the  display. 
However,  not  all  windows  are  monitoring  untrusted  programs. 

(2)  Windows  can  only  monitor  a  single  program. 

(3)  The  known  capabilities  in  the  untrusted  software  a^e  untrusted 
capabilities  that  are  also  available  to  the  monitoring  window  (the 
intersection  in  the  diagrams). 

(4)  All  the  known  capabilities  refer  to  the  grouc  object  for  the 
program,  le  they  could  be  related. 

(5)  The  classification  displayed  when  untrusted  software  is  running  is 
the  correct  high  water  mark  for  the  related  group. 

(G)  All  the  untrusted  capabilities  in  a  window  will  belong  to  sc~  e 
related  group  and  hence  have  a  high  water  mark  classification. 
However,  these  capabilities  are  not  necessarily  related  and  so  dz 
not  have  to  belong  to  the  same  group. 

ADISPLAY  £  C  DISPLAY’  ;  DI5PLAY  3 

EDISPLAY  £  [  ^DISPLAY  |  eDISPLAY ’  =  0DISPLAY  ] 

5 •  6  Display  Operations 

This  section  defines  the  operations  that  take  place  in  a  display  which  a^e 
concerned  with  the  windows  and  untrusted  software.  All  the  operations  in  Serous 
will  in  fact  be  initiated  from  a  window  in  a  display.  However  this  is  not  specified 
until  part  2. 
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5-6-1  create  a  window 


Creating  a  new  window  does  not  alter  the  high  water  marks  or  running  software. 
A  new  empty  window  is  simply  added  to  the  display- 

create  window 

bis  tc.op  * 

ADISPLAY 

SHIGHJJATERJ1ARKS 

new_wid  •-  UID 
empty_window  :  WINDOW 


new_wid  e  dom  which_window  (1) 

empty_window  t  ran  which_window  (2) 

empty_w i ndow. ava i lable  =  O  (3) 

wh  i  ch _ w  i  ndow’  =  which_window  U  {  new_wid  «  empty_window  > 

windows’  =  windows  U  {  new_wid  >  (4) 

programs’  =  programs  (5) 


(l&Z)  The  new  window  and  identifier  are  unique- 

13)  The  new  window  has  no  capabilities  available  to  it  initially.  The 
window  will  not  be  running  any  untrusted  software. 

(4&5)  The  new  window  is  added  to  the  display.  No  other  windows  or  any 
untrusted  software  is  affected. 

3. 6- 2  call  untrusted  software 

Untrusted  programs  can  only  be  initiated  from  a  window  in  a  display  that  is  not 
already  monitoring  any  untrusted  software.  P  new  group  object  will  be  created 
for  this  software-  Pll  the  capabilities  known  by  both  the  untrusted  and  the 
trusted  software  will  refer  to  this  group  to  indicate  that  they  could  be 
related.  Initially  the  untrusted  software  will  have  no  capabilities  available  to 
it  and  the  classification  will  be  the  lowest  possible. 

Hon i tor i ng  U i ndow 


Figure  4:  The  window  has  started  to  run  untrusted  software-  This 
software  has  no  capabilities  available  to  it  and  the 
classification  displayed  will  be  the  lowest  possible. 


24 


D i splays 


_ run  untrusted,, 

-  —  b  it  v  c  _o  P 


1 

ADISPLAY 

ETHE_WINDOWS 

wid7  :  WID 

prog!  ;  UNTRUSTED 
group!  :  GROUP 

wid7  e  windows 

wid7  £  {  p  :  programs  •  p. monitor 

i  ng  > 

(1  ) 

group!  £  dom  hwm_class 
which_group‘  =  wh i ch  group 
hwm_class‘  =  hwm_class  U  f  group! 

m  bottom  > 

(2  ) 

prog!  £  programs 
prog  .'.using  =  O 
prog!. group  =  group! 
prog1. class  =  show  bottom 
pr og ! . mon i tor i ng  =  w i d7 

(3  ) 

windows’  =  windows 

programs’  =  programs  U  f  prog’  > 

(4  ) 

(1)  Only  an  existing  window  that  is  not  already  monitoring  untrusted 
software  can  start  to  run  the  program. 

( 2 )  A  new  group  object  is  created/  and  added  to  the  high  water  ma'-ks 
function  with  a  classification  of  bottom.  Initially  there  are  no 
capabilities  belonging  to  the  group  (and  hence  the  which  g^oup 
function  is  unchanged). 

(3)  A  new  untrusted  program  is  created.  Initially  this  has  no 
capabilities  available  to  it.  The  group  for  this  software  is  the  new 
group  object. 

( 4 )  The  new  program  is  added  into  the  display.  No  windows  or  existing 
programs  are  affected  by  the  operation. 

5- 6. 3  add  to  untrusted 

This  operation  takes  capabilities  from  a  window  that  is  running  an  untested 
program  and  makes  them  available  to  the  software.  This  could  be  viewed  as  a 
‘cut  and  paste’  operation  or  as  passing  parameters  to  an  untrusted  function. 
This  operation  does  not  necessarily  take  place  between  the  software  and  the 
window  that  is  monitoring  it.  The  untrusted  software  could  be  in  a  completely 
separate  window.  Note  that  for  simplicity  all  the  following  diagrams  illustrate 
the  f irst  esse. 


Z5 


D i spl a>  s 


Bottom 


Figure  5a:  The  state  of  the  window  after  starting  to  run  an 
untrusted  program  and  prior  to  passing  capabilities  to 
the  untrusted  software. 


Restr i cted 


Figure  5b:  The  state  of  the  window  after  one  trusted  and  one 
untrusted  capability  have  been  added  to  the  untrusted 
software. 


A  new  group  object  will  be  created.  All  the  untrusted  capabilities  being  added 
to  the  software  are  made  to  refer  to  this  group.  Any  capabilities  that  could 
also  be  related  to  these  must  be  made  to  refer  to  the  new  group  as  well- 
However  these  extra  capabilities  may  not  in  fact  be  available  to  the  untrusted 
program,  the  worst  case  is  always  assumed. 


Secret 


Figure  5c:  After  a  further  untrusted  and  two  trusted  capabilities 
have  been  added. 
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_ give  to  untrusted, 

—  —  b  *  $  iC_OP 

^DISPLAY 

ETHE_WINDOWS 

wid7  :  WID 

prog7  :  UNTRUSTED 

caps7  :  P  CAPABILITY 

group!  :  GROUP 
groups!  :  P  GROUP 
prog!  :  UNTRUSTED 


w i d7  e  windows 
prog7  e  programs 

caps7  £  wh i ch_w i ndow(  wid7  ). available 

groups!  =  which_group  I  caps7  ) 
group!  4  dom  hwm_class 


prog 

prog 

prog 

prog 

prog 

prog 


i  programs 

•using  =  prog7. using  U  caps7 

•known  =  prog7. known  U  (  caps7  D  untrusted_caps  ) 
•monitoring  =  wid7 
•group  =  group! 

•class  =  show  hwm_class’  (  group1  ) 


which _ group"  C  domC  which_group  C>  groups!  )  J  =  f  group1  T 

which_group’  fr  groups!  =  which _group  groups! 


f 1  ) 
(2  J 

( 3  ) 
H  ) 

(5  ' 


(B  ) 
(7  ) 


dom  hwm_class’  =  (dom  hwm_class  \  groups!  )  U  -C  group!  >  (B) 

hwm_class’(  group!  )  =  LUB  {.  g:  groups!  •  hwm_class(  g  )  >  (3) 

(  groups'  U  -C  group!  >  )  4  hwm_class’  =  groups!  «  hwm_class  (ID) 


programs’  =  (  programs  \  {  prog7  >  )  U  T  prog!  >  (11  ) 

windows’  =  windows 


(1)  The  window  and  program  must  be  in  the  display.  However  the  program 
is  not  necessarily  being  monitored  by  this  window. 

(Z)  All  the  capabilities  being  given  to  the  software  are  available  to  the 
window . 

(3)  This  defines  the  set  of  related  groups  that  all  the  capabilities 
being  given  to  the  software  belong  to. 

(4)  A  new  group  object  is  created.  This  will  give  the  new  related  group 
and  high  water  mark  for  the  untrusted  software- 

(5)  A  new  untrusted  program  is  created.  This  has  the  same  capabilities 
available  as  the  program  the  window  is  running  plus  the  ne^ 
capabilities.  The  window  monitoring  the  untrusted  does  not  change- 

(68.7)  All  the  untrusted  capabilities  being  added,  and  those  that  they  a-e 
related  to.  are  made  to  refer  to  the  new  group.  All  other  related 
sets  are  unchanged. 

(8-10)  The  new  group  replaces  all  the  original  groups  in  the  high  water 
mark  classifications  relation.  The  high  water  mark  for  this  new 
group  is  the  least  upper  bound  of  all  the  classifications  of  the 
original  groups. 
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(11)  The  new  program  replaces  the  original  one  in  the  display-  No  windows 
are  affected. 

5  •  G -  4  take  from  untrusted 

This  operation  takes  capabilities  from  the  untrusted  software  and  adds  them  to 
a  trusted  window*  but  not  necessarily  the  window  that  is  running  the  program. 
This  set  of  capabilities  will  be  assumed  to  be  related  and  will  be  given  the  high 
water  mark  classification  associated  with  the  untrusted  software.  This  could  be 
viewed  as  either  a  ’cut  and  paste’  operation  or  as  returning  the  result  of  an 
untrusted  function. 


Conf i dent i al 


Figure  Sa:  The  state  of  the  window  before  the  operation. 


Conf i dent i al 


Figure  6b:  After  an  untrusted  capability  has  been  given  to  the 
monitoring  window. 
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_ take  from  untrusted, 

—  —  b  A  S  »C_OP 

ADISPLAY 

w i d7  :  UID 

prog7  :  UNTRU5TED 

caps7  :  P  CAPABILITY 

extra!  :  P  CAPABILITY 
window!  :  WINDOW 


w i d7  €  w i ndows  ( 1  ) 

prog7  e  programs  (2) 

caps7  C  prog7-using  (3) 

extra!  =  caps7  n  untr usted__caps 

n  (  prog7. using  \  prog7. known  )  (4) 

window!  4  ran  which_window 

w i ndow ! , ava i lable  =  wh i ch_w i ndow(  w i d7  ). available  U  extra1 
which  __w  i  n  d  o  w  '  =  which_window  ®  <  w  i  d7  «  window!  }  (5) 

which_group’  I  extra!  I  =  C  prog7. group  > 

extra!  which_group’  =  which_group  (6) 


hwm_class’  =  hwm_class 
windows’  =  windows 
programs'  =  programs 


(1-3)  The  window  and  program  are  in  the  display  (but  the  window  is  not 
necessarily  monitoring  the  program).  All  the  capabilities  are 
available  to  the  software- 

(4)  This  defines  the  set  of  untrusted  capabilities  being  given  to  the 
window  that  it  was  not  previously  aware  of. 

(5)  A  new  window  is  created.  The  capabilities  available  to  this  window 
are  those  available  to  the  initial  window*  plus  these  extra 
capabilities.  This  new  window  replaces  the  previous  window. 

(G)  The  extra  capabilities  now  belong  to  the  group  for  the  untrusted 
software-  No  other  groups  are  affected- 

5-E-5  complete  untrusted 


This  operation  destroys  the  untrusted  program  that  a  window  is  monitoring.  Th  s 
can  be  viewed  as  returning  from  an  untrusted  function  call*  and  will  probably 
only  be  done  when  results  have  been  given  to  the  window  by  the 
’  take_f rom_untrusted ’  operation  described  in  the  previous  section.  No  windows 
or  high  water  marks  are  affected  by  this  operation. 
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6.  Storing  Capabilities 

S  ■  1  Introduction 

Capabilities  may  be  kept  in  a  cupboard-  A  cupboard  is  simply  a  relationship 
between  names  and  the  capabilities  they  represent-  These  names  are 
represented  by  printable  character  strings-  Cupboards  are  similar  to 
dictionaries  or  directories- 

Any  type  of  capability  may  be  kept  in  the  cupboard-  However .  when  capabilit'es 
to  untrusted  objects  are  stored,  they  must  be  first  copied  to  avoid  the 
problems  of  related  sets  (refer  to  section  5-2).  and  the  high  water  mark 
classification  must  be  remembered  as  well- 

6 • 2  Cupboards 


CUPBOARD  _ _ 

name  :  STR  -  CAPABILITY  (1) 

class  :  CAPABILITY  -»  CLASS  (2) 


dom  class  =  (  ran  name  1  n  untrusted_caps  (3) 


(1)  The  relationship  between  names  and  capabilities  is  a  function 
because  each  name  can  only  refer  to  a  single  capability-  The 
function  is  partial  beacuse  not  all  strings  are  used.  There  are  no 
restrictions  concerning  naming  capabilities  more  than  once  in  the 
cupboard- 

(21  The  'untrusted  capabilities  to  classifications'  relationship  is  a 
function  because  there  is  a  Single  classification  for  each 
capability-  The  function  is  partial  because  only  some  capabilities 
are  kept  in  the  cupbaord- 

(31  The  cupboard  keeps  a  classification  for  all  the  untrusted 
capabilities  that  are  stored. 

ACUPBOARD  &  (  CUPBOARD’  ;  CUPBOARD  1 

-CUPBOARD  &  [  ACUPBOARD  |  eCUPBOARD '  =  eCUPBOARD  1 

6 • 2  Cupboard  Operations 

An  empty  cupboard  is  defined-  This  is  a  cupboard  with  no  named  capabilities  and 
consequently  no  stored  classifications  either. 

create_empty_cupboard _ ( 

I  empty_cupboar d  :  CUPBOARD 


empty_cupboard- name  =  O 


The  simple  operations  on  a  cupboard  are  find  and  keep. 

Looking  up  a  name  in  a  cupboard  will  return  the  stored  capability,  and  if  th.s  is 
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an  untrusted  capability  the  associated  classification  as  well-  The  contents  of 
the  cupboard  will  be  unaltered. 


r 

1 

ECUPBOARD 

(11 

name 

?  :  STR 

cap ! 

:  CAPABILITY 

cap ! 
cap ! 

=  name(  name?  1 
e  trusted_caps 

(2) 

ECUPBOARD 

(1  ) 

name7  =  STR 

cap!  :  CAPABILITY 
class!  :  CLASS 

cap!  =  name(  name7  1 

(2) 

cap!  e  untrusted_caps 
class!  =  class(  cap!  ) 

(3) 

—  --  -l 

(11  The  cupboard  is  unaffected  by  find- 

(21  The  capability  returned  is  the  the  one  that  was  stored  with  the 
given  name. 

(3)  If  the  capability  is  untrusted#  the  correct  classif ication  is 
returned. 

Keeping  a  capability  in  the  cupboard  adds  the  capability#  and  the  classification 
if  it  is  an  untrusted  capability#  under  the  supplied  name. 


tr  us  T  '  —  -  -  -  “  "  ’  1 

1 

ACUPBOARD 

name7 

:  STR 

cap7  : 

CAPABILITY 

cap7  e 

trusted_caps 

name7 

e  dom  name 

(1  1 

name’ 

=  name  U  -C  name7  «  cap7  > 

(2  1 

l 

ACUPBOARD 

name? 

:  STR 

cap7  : 

CAPABILITY 

class7 

:  CLASS 

cap7  e 

untrusted  caps 

name7 

£  dom  name 

(1  1 

name' 

=  name  U  -C  name7 

«  cap7  > 

(2  1 

class’ 

=  cl asm  u  {  cap7 

>-•  class7  > 

(3  1 

( 1 1  No  capability  has  already  been  stored  with  the  supplied  name- 

(21  The  new  name-capability  relation  is  added  to  the  cupboard.  No  other 
relationships  are  affected. 

(31  If  the  capability  being  added  is  untrusted#  its  classification  will 
also  be  remembered.  No  other  classifications  are  affected. 
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Note  that  what  is  in  fact  kept  in  the  cupboard  will  be  a  capability  tc 
a  copy  of  the  object.  This  removes  the  problem  side  effects  due  to 
operations  involvins  related  sets  of  capabilities,  and  is  fully 
specified  in  part  2. 


7.  Users 


7 . 1  Introduction 

As  in  the  paper  world  users  can  have  specific  roles.  In  Sercus  the  special  kinds 
of  users  are  ’system  security  officers’  and  're9istry  clerks'.  Only  registry 
clerks  will  be  able  to  create  new  files  and  only  security  officers  will  be  able 
to  regrade  documents  and  files.  Security  officers  will  also  be  able  to  change 
users  clearances  and  create  new  users. 

These  specific  roles  in  Sercus  will  be  indicated  by  a  user  having  a  clearance 
which  dominates  the  particular  classification. 

I  sso  :  CLASS 
I  clerk  :  CLASS 

For  example/  users  are  registry  clerks  if  their  clearance  dominates  the  clerk 
classification- 

7.2  The  Users  of  Sercus 
[  PASSWORD  1 

Users  of  sercus  will  have  a  password,  which  is  taken  from  the  given  set.  a 
clearance  and  a  cupboard  in  which  to  store  capabilities. 

USER _ , 

password  :  PASSWORD 
clearance  :  CLASS 
cupboard  :  CUPBOARD 


[  UID  ] 

Users  can  be  uniquely  identified  by  a  UID  taken  from  the  given  set.  At  least  one 
of  the  users  must  be  a  system  security  officer. 

THE  .USERS _ _ 

which.user  :  UID  >«  USER  (1) 

my.display  :  UID  **  DISPLAY  (2) 


dam  my.display  £  dom  which.user  (3) 

d  a.  b  :  ran  my.display  . 

dom  a.hwm.class  n  dom  b-hwm.class  *  0  ++  a  =  b  (4) 
a. windows  n  b. windows  *  O  «-»  a  =  b  (5) 

y  x.  y  :  ran  which.user  • 

x. cupboard  =  y. cupboard  ++  x  =  y  C 6  ) 

3  sec  :  ran  which.user  .  sec. clearance  2  sso  (7) 

_ _ _ _ _ _ _ _ _  _ i 


The  domain  of  the  which.user  function  gives  the  set  of  all  valid  user 
identifiers,  ie  the  legal  users,  and  the  range  all  the  users.  Similarly  the 
range  of  the  my.display  function  gives  all  the  valid  displays. 

(1)  Since  the  relationship  between  the  user  identifiers  and  the  users  is 
a  function,  there  is  a  single  user  associated  with  each  identifier. 
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The  function  is  partial  so  that  new  users  can  be  3dded  tu  e 
system  and  one  +n  one  sc  that  each  user  has  a  single  identifier. 

(2)  The  display  will  be  frequently  altered  by  the  operations  that  users 
perform.  Hence  there  is  a  mapping  from  users  to  their  displays. 

The  relationship  is  a  function  because  each  user  can  only  have  a 
single  display,  partial  so  that  new  users  can  log  in  and  one  to  one 
so  that  each  display  only  belongs  to  a  single  user. 

(3)  Not  all  valid  users  need  have  a  display  associated  with  them. 
Obviously,  the  users  who  are  not  currently  logged  in  will  not  have  a 
display . 

(“11  This  predicate  states  that  no  two  users  can  have  the  same  group 
object  associated  with  their  displays.  Group  objects  define  the 
sets  of  related  capabilities.  This  means  that  only  a  single  user  can 
have  a  capability  for  an  untrusted  object,  and  hence  that  users 
are  not  related. 

(58,5)  Users  cannot  share  windows  or  cupboards- 

(7)  There  must  be  at  least  one  security  officer. 

ATHE  JJSERS  &  [  THE JJSERS ’  ;  THE  JJSERS  1 

3THEJJSERS  &  l  ATHEJJSERS  |  eTHE JJSERS’  =  eTHE JJ5ERS  1 

There  will  be  a  group  of  users  who  are  currently  logged  on  to  Sercus.  These 
must  be  valid  users,  le  have  a  user  identifier  associated  with  them. 


THE  U5ER5 

logged_i n 

:  P  UID 

(1  ) 

logged_i n 

Z  dom  which_user 

(2) 

dom  my_d i 

splay  =  logged_in 

(3  ) 

_ _ 1 

(1)  Users  can  only  be  logged  in  once,  and  hence  this  is  a  set. 

(2)  Only  valid  users  may  use  5ercus. 

(3)  fill  the  logged  in  users,  and  only  these,  will  have  a  display 
associated  with  them. 

AU5ER_STATE  &  l  USER.STATE’  ;  USER_STATE  1 
HUSER__STATE  a  [  AU5ER_STATE  |  8USER_5TATE’  =  eU5ER_5TATE  1 
7. 3  User  Operations 

This  section  describes  the  basic  user  operations  such  as  logging  in  and  out.  The 
filing  system  and  display  operations  described  earlier  will  also  be  performed  by 
users,  but  this  will  be  specified  in  part  2- 

A  facility  to  explicity  delete  the  users  of  Sercus  will  not  be  provded.  Instead 
there  will  be  an  ’authorised’  classification.  Users  will  only  be  able  to  log  on  if 
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their  clearance  dominates  this  classification.  Changing  a  users  clearance  so 
that  it  is  dominated  by  ’authorised’  will  therefore  effectively  remove  them. 


authorised  :  CLASS 

7.3.1  create  a  new  user 

To  create  a  user,  a  new  identifier,  password  and  clearance  must  be  supplied.  A 
new  user  with  this  password  and  an  empty  cupboard  is  added  to  the  valid  users, 
e  the  which_user  function.  New  users  will  not  be  logged  on  so  will  have  no 
displays  associated  with  them.  No  other  users  are  affected. 

create  user 

b  At i C  _0  P 

flUSER_STATE 

u  i  d7  :  UID 

password7  :  PASSWORD 
clearance7  :  CLASS 

new_user !  :  USER 
create.  empty_cupboard 

u i d7  £  dom  which_user 

(1  ) 

new_user !  g  ran  which_user 

(Z  ) 

new_user !. password  =  password? 
r,ew_user  !.  clearance  =  clearance7 
new_user !. cupboard  =  empty_cupboar d 

(3  ) 

which_user’  =  which_user  U  {  u i d?  «  new_user !  > 
rny_di splay’  =  my_di splay 
logged_in’  =  logged_in 

) 

(l&Z)  The  user  identifier  and  user  do  not  alreadv  exist. 

(3)  The  new  user  is  given  the  supplied  password  and  clearance/  and  an 
empty  cupboard. 

(4)  The  new  user  becomes  a  valid  user*  and  no  other  users  are 
affected. 

Note  that  the  ability  to  create  new  users  is  resticted  to  the 
system  security  officers,  and  is  fully  specified  in  part  Z. 

7. 3- Z  log  in 

To  log  onto  Sercus  a  user  identifier  and  password  must  be  supplied-  The  user 
must  be  authorised  to  use  Sercus.  cannot  already  be  logged  on  and  must  supply 
the  correct  password. 

_ create_i  n  i  t  i  al_d  i  splay  _ , 

USER_5TATE 
create_w  i  ndowkiJ  ,c 

i n i t i al_d i splay  :  DISPLAY 


i n 1 1 1 al_d i splay  g  ran  my_di splay 
i n i t i al_di splay . w i ndows  =  <  new_wid  > 
i n i t i al_d i splay • programs  =  O 


AUSER_STATE 
uid7  :  UID 

password7  :  PASSWORD 
create  initial  display 


u i d?  i  lo9sed_i n 

uhich_user(  u i d7  )• password  =  password7 
which_user(  u i d7  ). clearance  2  authorised 

wh  i  ch_w  i  ndow  ’  =  which_window  U  {  new_wid  «  empty_window  > 
my_display’  =  my_display  U  {  u i d7  «  i n i t i al _d i splay  T 

logged_in’  =  logged_in  U  -C  u  i  d7  } 
which  user’  =  which  user 


Cl)  The  user  is  not  already  logged  on. 

C2&3)  The  supplied  password  must  be  correct,  and  tue  user  must  b 
authorised  to  use  the  system. 

(4)  The  display  for  this  user  consists  of  a  new  window  which  has  n 
capabilities  available  to  it.  No  other  displays  are  altered. 

C5)  This  user  is  now  added  to  the  set  of  logged  on  users-  No  othe 
users,  nor  any  passwords  or  clearances  are  affected. 

7.3-3  log  out 

In  order  to  log  out,  users  must  obviously  be  logged  in.  The  user  .dentifie 
display  are  simply  removed  from  the  logged_in  set- 

rlcg  outL  _ 

b‘“c-op 

flUSER  STATE 


u i d7  e  logged_i n 

my_display'  =  {  uid7  }  <  my_di splay 
which_user’  =  which_user 

logged_in‘  =  logged_m  \  <  u  i  d7  > 


(1)  The  users  display  is  deleted- 

(2)  No  passwords,  clearances  or  cupboards  are  affected. 

(3)  The  user  is  removed  from  the  logged_in  set. 

7.3.4  change  clearance 


Users  may  have  their  clearances  reviewed  by  the  security  officer 


simplicity  of  implementation,  clearances  may  only  be  changed  when  users  are 
not  logged  on. 


_ change_clearanceL 

bit ic.op 

AUSER_STATE 

uid7  :  UID 
clearance7  :  CLASS 

user!  :  USER 


u  i  d7 

e  dom  which 

user 

u  i  d7 

£  logged_in 

(1  ) 

user ! 

•clearance  ■ 

=  c 

lear ance7 

(2  ) 

user  ! 

.password  = 

wh 

i ch_user ( 

u  i 

d7 

).  password 

user  ! 

.cupboard  = 

wh 

i ch_user ( 

u  i 

d7 

).  cupboard 

wh  i  ch 

_user’  =  wh 

i  ch 

_user  ®  f 

u  i 

d7 

«  user  !  }■ 

£3  ) 

my_d  i 

splay’  =  my 

_d  i 

splay 

logged_in'  =  logged. 

_i  n 

(11  Users  clearances  can  only  be  changed  when  they  are  logged  out. 

(2)  Only  the  particular  users  clearance  is  changed. 

(3)  No  other  users  are  affected. 

7.3.5  change  password 


Users  may  alter  their  password. 

change_passwordkific_g|> - 

AUSER_STATE 
uid7  :  UID 

password7  :  PASSUORD 
user !  :  USER 


u  i  d7 

e  dom  which 

_user 

u  i  d7 

e  logged_in 

(1  ) 

user  ! 

•password  = 

password7 

(2  ) 

user  ! 

•clearance  : 

=  which_userl 

uid7 

).  clear ance 

user  ! 

•cupboard  = 

wh i ch_user  ( 

uid7  ). 

•  cupboard 

wh  i  ch 

i_user '  =  wh 

ich_user  ®  -C 

uid7  >-» 

user!  > 

(3  ) 

my_d  i 

splay’  =  my. 

_d  i splay 

logged_in’  =  lo9ged_in 

(1)  Users  must  be  logged  in  to  change  their  password. 

(2)  Only  the  user’s  password  is  changed. 

(3)  No  other  users  are  affected. 


Users 
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B.  Messages 

8  ■  1  Introduction 


5ercus  will  allow  simple  mail  messages  to  be  sent  to  users.  These  message 
will  be  used  by  the  users  to  request  operations  from  the  registry  clerks  c 
security  officer  and  possibly  also  to  send  documents  and  files  to  other  users- 

8  •  2  About  Messages 

A  message  contains  capabilities  and  an  indication  of  which  user  sent  the  messag 
and  when.  The  textual  part  of  a  message  is  uninteresting  as  far  as  tn 
specification  is  concerned. 

MESSAGE  _ , 


message  :  P  CAPABILITY 

from  :  UID 

time  ;  TIME 

message  £  trusted_caps 

(1  ) 

» 

(1)  Messages  may  only  contain  capabilities  for  trusted  objects-  such  as 
documents  and  files- 

Note  that  untrusted  capab'lities  could  be  sent  if  the  objects  were 
copied  first.  However  for  the  purposes  of  Serous-  messages  as 
specified  should  be  sufficient. 


8-3  Mail 


The  mail  system  in  Sercus  relates  messages  to  the  recipient. 


_ MAI! _ , 

mail  :  ME55AGE  ~  UID 

_ I 


AMAIL  &  [  MAIL'  ;  MAIL  1 

EMAIL  &  [  AMAIL  |  8MAIL ’  =  9MAIL  ] 

8 •  4  Mail  Operations 

Sending  a  message  involves  supplying  some  capabilities-  and  the  apprcpmat 
user  identifiers.  Both  trusted  and  untrusted  capabilities  will  be  used  to  crest 
a  message,  the  contents  of  the  untrusted  ones  making  up  the  unspecifie 
textual  part  of  the  message- 
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-  b  AS  i  C 

~~  —  1 

AMAIL 

caps7  : 
me?,  to7 

P  CAPABILITY 
:  UID 

message ! 

:  MESSAGE 

message ! 
message ! 
message ! 
message ! 

i  dom  ma i 1 
.message  =  caps7 
.from  =  me7 
.time  =  t i me_now 

D  trusted_caps 

(1  ) 

mail’  = 

mail  U  <  message 

«■  to?  > 

(Z  ) 

i 

(1)  A  new  message  is  created  which  contains  only  those  capabilities 
which  are  trusted. 

(Z)  This  message  is  added  to  the  mail  system.  No  other  messages  are 
affected. 

This  operation  opens  the  next  message  for  the  particular  user.  Opening 
message  simply  makes  the  capabilities  available. 


_ opennext.message, 

I -  —  —  J  btf  ic_op 


~  -  biilC_UP 

AMAIL 

message7  :  MESSAGE 
me7  :  UID 

caps!  :  P  CAPABILITY 

ma  i  1  ( 

message7  )  =  me7 

(1  ) 

W  m  : 

dom  (  mail  0  {  me7  >  1 

m  *  message7  • 

message7. t i me  £  m.time 

(Z  ) 

caps ! 
mail' 

=  message7- message 
=  -C  message7  >  4  mail 

(3  ) 

• 

(1)  Messages  may  only  be  opened  by  the  user  they  are  destined  for. 

C Z )  Messages  are  opened  in  the  order  in  which  they  were  sent. 

In  order  to  avoid  the  difficulties  of  two  messages  being  sent  at  the 
same  time,  it  is  assumed  that  either  time  is  defined  with  sufficient 
granularity  to  prevent  this,  or  that  the  mailing  system  software 
will  randomly  choose  between  messages  with  identical  times-  Since 
the  'S'  operator  is  not  fully  specified  it  could  do  this  random 
choosing . 

(3)  The  opened  message  is  removed  from  the  mail  system. 
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9.  Journalling 

C  EUENT_TYPE  ] 

Security  critical  operations  are  recorded  in  a  journal-  This  is  a  sequence  rf 
events^  which  are  taken  from  the  given  set/  together  with  the  identity  of  the 
|  user  who  caused  the  event  to  occur  and  when  it  happened- 

EUENT _ , 

event  :  EUENT_TYPE 
caused_by  :  HID 
time  :  TIHE 


The  types  of  event  journalled  can  be  partioned  into  three- 


document_events /  f 

le_eventsz  user_events  :  P  EUENT_TYPE 

<  document_events / 

file_events/  user_events  > 

partition  EUENT_TYPE 

I  The  possible  journalled  events  are: 

documentor  eated  /  document_opened /  document_regraded / 

|  f i le_cr eated ,  f i le_r egr aded . 

user _cr eated .  clear ance_changed .  :  EUENT_TYPE 


document_events  = 

<  document_created .  document_opened/document_regraded  > 
file_events  =  f  f i le_created /  f i le_regraded  > 
user_events  =  {.  user _cr eated/  clear ance_changed  > 

A  journal  is  an  ordered  sequence  of  events- 

JOURNAI _ 


journal  :  seq 

EUENT 

U  i /  j  :  dom 

journal  |  i  <  j  • 

journall  i 

).t  ime  <  journall  j  ).time 

(1  ) 

l 

(1)  The  journal  is  ordered  on  time- 

Operations  can  add  an  entry  to  a  journal/  but  never  remove  or  replace  existing 
entries . 

6J0URNAI _ , 

JOURNAL’ 

JOURNAL 


wjournal’  =  ^journal  a  journal’  =  journal 

V 

^journal’  >  Wjournal  a  frontl  journal’  )  =  journal 


EJOURNAL  &  l  ^JOURNAL  |  SJOURNAL’  =  eJDURNAL  1 


Journall  ing 


9. 1  Journalling  the  Filing  System 


All  the  documents  and  files  in  Sercus  will  have  a  journal  associated  with  them, 
although  this  cannot  be  insisted  upon  until  part  2. 

JOURNAL.DOCS _ _ _ _ 

I  document_journal  :  CAPABILITY  JOURNAL  (1) 


dom  document_journal  £  caps_for_docs 
d  j  :  ran  document_journal  • 

•C  e  :  ran  j. journal  •  e. event  )■  £  document_events  (2) 
#  j . journal  2  1  ( 3  ) 
j. journal (  1  )-event  =  document_created  (4) 


The  document_journal  function  maps  the  document  capabilities  to  their  journals- 
The  domain  of  this  function  will  be  all  the  capabilities  for  documents  so  far 
created. 

(1)  The  relationship  between  documents  and  journals  is  a  function  so 
that  each  document  has  a  single  journal  associated  with  it.  The 
function  is  one  to  one  because  each  document  has  a  unique  journal, 
and  partial  because  not  all  the  possible  documents  have  yet  been 
created. 

(2)  Only  document  type  events  can  be  in  a  document  journal. 

(38,"U  There  must  be  at  least  one  event  in  any  document  journal,  and  the 
first  event  will  be  its  creation. 

flJOURNAL.DOCS  ft  [  JOURNAL.DOCS'  ;  JOURNAL _D0CS  ] 

SJOURNAL.DOCS  ft  [  AJOURNAL.DOCS  |  0JOURNAL_DOC5 ’  =  9J0URNAL_D0C5  ] 

Similarly  for  files: 

JOURNAL_FILES _ _ 

file.journal  :  CAPABILITY  m  JOURNAL 


dom  file_journal  £  caps_for _f i les 

d  j  :  ran  file_journal  • 

■C  e  :  ran  j. journal  •  e. event  >  E  file_events 
ttj. journal  i  1 

j.journaK  1  ). event  =  file_created 


AJOURNAL.FILES  ft  C  JOURNAL .FILES'  ;  JOURNAL.FILES  ] 

HJOURNAL.FILES  ft  [  ^JOURNAL  FILES 

I  0JOURNAL_FILES'  =  0JDURNAL.FILE5  1 

Adding  to  a  document  or  file  journal  will  always  involve  a  capability  to  a 
document  or  file  as  appropriate,  a  user  identifier  and  an  event  type. 
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1  ■  w 


_ document  op  ... 

journalled  -  —  —  —  - -  —  - ' - 

AJDURNAL.DOCS 

AJOURNAL  {this  defines  how  the  journal  is  changed! 


doc_cap7  :  CAPABILITY 
event 7  :  EUENT_TYPE 
caused_by7  :  U I D 


document_journal (  doc_cap7  )  =  eJOURNAL  (1) 

document_j ournal  ’  =  document_j ournal  ©  {  doc_cap7  «  eJDURNAL’  > 

journal’  =  journal  ~  <  [  EUENT  f  event  =  event7  C  Z  J 

caused_by  =  caused_by7 
time  =  t i me_now  1  > 


(1)  Only  the  particular  journal  is  changed. 

C23  A  new  entry  is  added  to  the  particular  journal  with  the  supplied 
event  and  user  identifier.  The  time  is  set  to  be  the  current  time. 

Similarly  for  adding  to  a  file  journal: 


AJOURNAL_FILES 

AJOURNAL 

f i le_cep7  :  CAPABILITY 
event7  :  EUENT_TYPE 
caused_by7  :  UID 


f i le _ journal (  f i le_cap7  )  =  eJOURNAL 

f i le_journal ’  =  file_journal  ®  {  f : le_cap7  ~  eJDURNAL’  > 

journal’  =  journal  ~  <  [  EUENT  |  event  =  event7 

caused_by  =  caused_by7 
time  =  t i me_now  1  > 


Whenever  files  and  documents  are  created  a  new  journal  will  be  created  and 
added  to  the  appropriate  journalling  function. 

_ create  document  op  . 

—  j  our  n*  1  lt(i  ~  - - - - - 1 

AJQURNAL_DOCS 

new_cap7  :  CAPABILITY 
caused_by7  :  UID 

journal!  :  JOURNAL 


journal!  t  ran  document_journal  (1) 

document_journal ’  =  document_journal  U  {  new_cap7  «  journal!  > 

journal!  =  [  <  [  EUENT  |  event  =  document_created  (2) 

caused_by  ~  caused_by7 

time  =  t i me_now  ]  >  ] 


(1)  A  new  journal  is  created  and  added  to  the  document  journal 
function.  No  other  journals  are  affected. 
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(21  The  new  journal  contains  a  sin9le  event.  This  is  a 
' document_created’  event/  with  the  supplied  user  identifier  and 
current  time- 

Similarly  for  files: 

_ create  file  op.  ,,  _ _ _ 

AJOURNAL_FILES 

new_cap?  :  CAPABILITY 
caused_by?  :  UID 

journal !  :  JOURNAL 


journal!  £  ran  file_journal 

f  i  le_ journal  =  file_journal  U  {  new^ap7  journal!  > 

journal!  =  [  <  [  EUENT  |  event  =  file_created 

caused_by  *  caused_by7 
1 1  me  =  1 1  me_now  1  >1 


3. 2  Journalling  the  Users 

There  is  a  journal  associated  with  each  user  identifier.  The  journal  for  users 
will  record  creation  and  changes  in  clearances  and  the  user  identifier  of  the 
user  who  performed  the  change-  Logging  in  and  out  and  changing  passwords  are 
not  journalled  in  this  example  system/  as  it  will  not  demonstrate  anything  new. 

_  JOURNAL_USERS _ , 


user_ 

journal  : 

UID  >~  JOURNAL 

(1  1 

b  j  : 

ran  user 

_journal  • 

< 

e  :  ran  j 

.journal  •  e-event  >  c  user  events 

(2  1 

. journal 

2  1 

(3  1 

J  • 

journal ( 

1  1. event  =  user_created 

(4  ) 

i 

(11  The  relationship  between  users  and  journals  is  a  one  to  one  function 
because  users  have  a  single  unique  journal  associated  with  them, 
and  partial  because  not  all  the  possible  users  have  yet  been 
created. 

(21  Only  user  type  events  can  be  in  a  user  journal. 

(384)  There  must  be  at  least  one  event  in  any  user  journal,  and  the  first 
event  will  be  creation  of  the  user. 

A  JOURNALJJSERS  £  [  JOURNALJJSERS’  ;  JOURNAL JJSERS  1 

E JOURNAL  JJSER5  £  I  AJOURNAL  JJSER5 

|  e JOURNAL JJSER5 ’  =  e JOURNALJJSERS  1 


Journal 1 i ng 
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As  for  documents  and  files  user  operations  will  add  to  the  journal. 


user  op  , .  .  _ 

—  ^  j  our  n*  1  1  »d  - 

AJ0URNALJJSER5 

AJOURNAL 

user'7  :  UID 
caused_by7  :  DID 
event7  :  EUENT_TYPE 


user_journal (  user7  )  =  0JOURNAL 

user_journal  ’  =  user_journal  e  -C  user7  «  8J0URNAL’  > 

journal’  =  journal  ~  <  [  EUENT  |  event  =  event7 

caused_by  =  caused_by7 
time1  t ime_now  ]  ) 


(1)  This  is  the  user  that  the  operation  is  performed  on. 

(2)  This  gives  the  identifier  of  the  user  who  performed  the  operat'on. 

As  for  documents  and  files,  whenever  a  new  user  is  created  a  new  journal 
be  added  to  the  journalling  function. 


.create  user  op 
AJOURNALJJSERS 


j  our  n4 l 1 


new_user7,  caused_by7  :  UID 
journal !  :  JOURNAL 


journal!  e  ran  user_journal 

user_journal  ’  =  user_journal  U  {.  new_user7  «  journal!  > 

journal!  =  [  (  t  EUENT  |  event  =  user_created 

caused_by  =  caused_by7 
time  =  time  now  ]  >  ] 


Journal  1 i ng 


Part  2 


The  previous  sections  described  the  various  components  of  Sercus 
independently/  le  the  documents  and  files#  displays,  cupboards,  use^s, 
messages  and  journals-  The  remainder  of  the  document  defines  how  these  base 
operations  are  performed  by  the  users  and  initiated  from  one  of  the  windows  in 
their  display.  Further  constraints  will  be  added  to  the  basic  operations  as  the 
system  is  built  up. 


Trusted  capabilities  are  those  that  refer  to  files  and  documents. 

I  caps_f or _docs  U  caps_for_f i les  =  trusted_caps 
|  caps_for_anon  =  untr usted_caps 
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10.  The  Journalled  Filing  System 


Many  of  the  filing  system  operations  described  earlier  [section  3.G)  will  result 
in  a  journal  entry  being  added  to  the  appropriate  journal.  To  this  end  the 
journalled  filing  system  is  defined,  and  all  the  basic  operations  will  be 
performed  on  this  system  rather  than  the  filing  system  alone. 


_  J0URNALL£D_FILlNG_SYSTEf1 


FILING  SYSTEM 

JOURNAL  DOCS 
JOURNAL_FILES 

dom  document  journal  = 

dom  which  doc 

(1  ) 

dom  file_journal  =  dom 

wh i ch_f i le 

(Z) 

_ _ 1 

(l&Z)  All  the  documents  and  files  in  Sercus  have  a  journal  associated  with 
them. 

GJOURNALLEO_FILING_SYSTEM  &  t  JOURNALLED  FILING_SY5TEri’ ; 

J0URNALLED_FILING_SY5TEn  1 

EJ0URNALLED_FILING_SYSTEI1  &  C  flJOURNALLED_FILING_SYSTEM; 

|  eJ0URNALLED_FILING_5Y5TEM’ 

=  0JOURNALLED_FILING_SY5TEM 

] 

The  following  schemas  define  all  the  basic  filing  system  operations  to  take 
place  on  the  journalled  system.  These  operations  will  either  involve  no  change 
to  any  journals,  or  will  simply  add  an  event  describing  the  operation  to  the 
appropriate  journal. 


create_document .  . ,  , 

j  our  nil  ltdi 

create_documentb4jic_op  »  create_document_op.#urMll.4 
A  EJ0URNAL_FILE5 


create  file  , .  . 
create  f i le,. 

—  b  AS  iC_op 


create  file  op  , ,  ,  a  EJOURNAL_DOC5 

— ’  —  J  our  n*  11  ed 


regrade_documentjourniU.d  _ 

AJ0URNALLED_FILING_SY5TEf1 

EJOURNAL_FILES 


documentop.  ,,  . 

our  nailed 

regrade  document,. 

9*S lC_Op 


event?  =  document_r egraded 

_ i 


_ regr ade_f i le .  , 

r~  —  journalled 


AJOURNALLED  FILING_SYSTEh 
EJ0URNAL_D0C5 

f  i  le  op  .  ... 

—  4  our  rt*  i  1  ed 

regrade_f  i  le. 

—  b  AS  1C  OP 


event?  =  f i le_regraded 


Journalled  Filing  System 


4? 


resd_document j0(jrlltllei  - 

AJOURNALLED_FILING_SYSTEn 

EJOURNAL_FILES 

document_op  , ,  . 

~  j  our  na  1  1  ed 

reaa  document, 

—  blS IC^OP 


event7  =  document_opened 


The  following  filing  system  operations  do  not  result  in  any  jojT.alle 
inf  ormation : 

regrade_f  ile_t.tlejournall#i  £  regarde_f  i  le_t .  t lefci$ iC_op 

a  SJQURNALLED_FILING_5YSTEn 

Regrading  the  class. f ication  of  the  title  of  a  file  is  not  journalled 
only  because  it  does  not  demonstrate  anything  new-  It  a  large^ 
system  all  changes  ot  ciassif.r'ticn  would  be  journalled. 

add  doc  to_file.  , ,  .  £  add  doc  to  file. 

—  —  jour  nilltd  —  —  —  bis  ic.op 

A  EJ0L)RMALLED_FILIN5_SY5TEM 

Adding  a  document  to  a  file  is  not  journalled  because  all  accesses 
to  each  document  will  still  be  controlled  and  journalled  as  for 
unfiled  documents. 


l.st_cdr j#urnin.d  £  list_cdrk4tic_o(>  A  EJOURNALLED_FILlNG_SYSTEh 
f  i  nd^ .document  , ,  ,  £  find  document. 

journalled  —  basic. op 

a  =J0URNALLED_FILING_5YSTEn 
f i nd_f i led_document  .  £  find  filed  document 

journalled  —  —  bas»c.oP 

a  =JOURNALlED_FILlMG_SYSTEh 
file  c o n t e n t s  ..  .  £  file  contents. 

journalled  —  basic. op 

a  EJQURNALLED_FILING_5>'5TEh 


The  act  of  aqumng  a  capability  for  an  object  is  not  journalled 
because  having  the  capability  does  not  automatically  allow 
operations  to  take  place.  All  the  relevant  actions  will  be 
journalled  separately. 
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11.  Journalling  Users 


Many  of  the  operations  performed  upon  the  users  of  Sercus/  such  as  changing 
clearances,  need  to  be  journalled.  To  this  end  the  journalled  user  state  is 
defined.  The  user  operations  defined  in  section  7.3  will  be  performed  in  this 
system  rather  th3n  the  basic  or.e. 

J0URNALLED_U5ER_STATE _ _ 

USER_STATE 

JOURNAL  JJSERS 


dom  user_journal  =  dom  which_user  (  1  ) 


(1)  All  the  valid  users  have  a  journal  associated  with  them. 


AJOURNALLED_USER_STATE  a  [  JOURNALLED JJSER_STATE’  ; 

J0URNALLED_USER_5TATE 

] 


H JOURNALLED  USER_STATE  a  i 


1 


AJOURNALLEDJJSER_STATE 
8J0URNALLED_USER_STATE * 

=  eJOURNALLED  USER_STATE 


For  simplicity,  only  creating  users  and  changing  their  clearances  will  be 
journalled. 


create_user 


j  our  n *  1 1 04 


fi  create_user.  [  uid7  /  new_user7 

b  Af 1C .op 

A  cr eat e_user_opj0(iri>4ll#i 


3 


change_cl ear ance .  our 


change_clearancek<i  ,e  [  uid7  /  user?  ] 
user  op  . ,  . 

—  ^  j  our  no  1 1  *4 


event7  =  clearance_changed 


These  basic  operations  need  to  have  the  identifier  of  the  particular 
user  renamed  to  be  consistent  with  the  names  that  the  journalling 
schemas  use. 

lo9-injourn«n.i  *  lo9-ir\*,ic_o,  *  EJOURNAL .USERS 

logout. ourniU#<t  &  lo9_outk4iie_0p  a  EJ0URNALJJ5ERS 

change  Password . .  , ,  .  £  change_passwordL  ,  a  EJOURNALJJSERS 

jourmiiod  bit  »c_op 
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12.  Promoting  the  Operations  Involving  Capabilities 


Operations  in  Serous  will  be  performed  by  the  users,  or  software  runn.ng  on 
their  behalf,  from  one  of  the  windows  of  their  display.  The  filing  syste~  . 
cupboard  and  mail  operations  may  alter  the  set  of  capabilities  available  to  tu e 
window,  but  will  not  create  or  destroy  windows  and  programs-  The  fcllo~ng 
schema  defines  this  situation. 

AOP 

—  CAPlbility  - - 

ADI5PLAY  {this  defines  how  the  display  alters! 

window_id7  :  HID  {this  identifies  the  particular  window! 

AWINDOW  {this  defines  how  the  window  alters! 

AUNTRUSTED  {this  defines  how  untrusted  software  alters! 


window_id7  e  windows  ( 1  J 

SWINDON  =  which _ w i n d o w (  window_id7  '  (2) 

wh  i  ch_w  i  ndow  ’  =  which_window  ®  {  window_id7  w  0UIINDOW  >  (3) 

windows’  =  windows  C4) 

window_id7  ft  {  p  :  programs  •  p. monitoring  !  *-*  (5) 

programs’  =  programs 

window_id7  =  monitoring  (B) 


programs’  =  programs  \  {  6UNTRU5TED  !  u  {  6UNTRU5TED’  > 
monitoring’  =  monitoring 


(1-3)  The  window  in  question  is  one  of  those  in  the  display,  and  it  is  this, 
and  only  this,  window  that  will  be  changed  by  the  operation. 

('ll  No  windows  are  created  or  destroyed  in  the  display. 

(5)  If  the  window  is  not  monitoring  any  untrusted  software  then  none  W'll 
be  changed  by  the  operation. 

(B)  If  the  window  is  monitoring  untrusted  software  then  it  is  this,  and 
only  this,  software  that  will  be  altered  by  the  operation.  The 
window  continues  to  monitor  the  software- 

Security  critical  operations,  and  some  operations  that  need  to  be  prope^lv 
controlled  to  prevent  untrusted  software  exploiting  signalling  channels  ISi, 
must  be  performed  on  the  trusted  path.  In  a  display  those  windows  that  are  not 
running  untrusted  software  form  the  trusted  path.  These  operations  will  not 
alter  any  high  water  mark  classifications  or  related  groups  of  untrustec 
capabilities . 

__  TRUSTED  PATH  .  ,  ,  _ _ 

—  CAPAbility  1 

AOP 

edibility 

EHIGH_WATER_MARKS  (1) 


wmdow_id7  t  {  p  :  programs  •  p. monitoring  >  (2) 

- - - i 

(1)  Operations  on  the  trusted  path  will  not  alter  any  high  water  marks 
or  related  groups  of  untrusted  capabilities. 
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(2)  Trusted  path  windows  are  only  those  that  are  not  monitoring  any 
untrusted  software. 

Operations  are  performed  by  users  in  one  of  the  windows  of  their  display.  The 
password*  clearance  and  cupboard  will  be  unaltered  by  the  filing  system  and 
mail  operations.  No  other  users  will  be  directly  affected  by  these  operations 
that  a  user  can  perform. 

—  ®^fiIin»_*si*«««USER_STATE  - ' 

AJ0URNALLED_USER_5TATE 

5J0URNALJJSERS 

caused_by?  :  UID  {this  is  the  user  performing  the  operation} 


(1)  The  display  for  the  particular  user  will  be  altered  by  operations- 
No  other  users  displays  will  be  changed. 

(2)  The  password,  clearance  and  cupboard  remain  the  same. 

Note  that  no  journalling  information  about  the  users  is  added-  This 
is  because  each  document  and  file  maintains  its  own  journal  of 
accesses  and  regrades. 

Some  of  the  operations  in  Sercus  must  be  performed  by  specific  users,  such  as 
security  officers  or  registry  clerks- 


5S0  e  [  t»»usER_sT«Te 

|  which_user(  caused_by'7  ).  clearance  2  sso  ] 

CLERK  *  [  ®0P,iUns_tsst..USER_STflTE 

I  which_user(  caused_by?  ). clearance  >  clerk  ] 

The  operations  upon  the  cupboard  do  not  alter  the  display  except  by  adding 
capabilities  to  the  window  that  the  operation  is  performed  from.  These 
operations  are  performed  by  a  user,  and  will  not  alter  the  password  or 
clearance. 
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c  u  pb o*r  dUSER_STATE 


$0P 


uwi  ,  ,  , 

c  A  P  *  b  ihty 

AUSER_STATE 

AUSER 

ACUPBOARD  {this  defines  how  the  cupboard  changes} 

caused_by7  :  UID 


my_di splay  (  caused_by7  )  -  eDISPLAY 

my_display’  =  my_display  ®  {  caused_by7  >-•  9DI5PLAY'  }  (1) 

which_user(  caused_by7  )  =  0USER 

which_user’  =  which_user  ®  {  caused_by7  *-*  6USER'  }  (2) 

cupboard  =  eCUPBOARD  (3) 

cupboard’  =  6CLJPBQ--  -^0’ 
password’  =  password 
clearance’  =  clearance 

logged_in'  =  lo99ed_in 


(11  The  display  for  the  particular  user  will  be  altered  by  operations/ 
and  no  others . 

(ZS.31  The  cupboard  is  altered  by  the  operation,  but  the  Password  a^d 
clearance  remain  the  same- 


13.  The  Operations  upon  the  Filing  System 
13-1  Filing  System  Operations  in  a  Display 


The  journalled  filing  system  operations  described  in  section  10  will  be 
performed  in  a  particular  window  and  display,  and  may  alter  the  contents  of  the 
window . 

The  only  security  critical  operations  on  the  filing  system  are  regrading 
documents  and  files.  However,  it  would  be  inconvenient  if  Trojan  Horses  in 
untrusted  software  created  files  or  documents  and  added  documents  to  files  in 
a  random  manner.  In  fact  if  other  untrusted  software  cooperated,  this  could 
form  a  significant  signalling  channel.  To  prevent  this,  these  operations  can 
only  be  performed  from  the  trusted  path. 

r egrade_documentTP_F[LING_SYSTEn  - - 

TRUSTED  PATH  . , 

—  C  A PAb i 1  a  t  y 

regrade  document.  , ,  , 


doc_cap?  e  available 

eWINOOW’  =  eWINDOW 


Cl  ) 
(2) 


(1)  This  is  the  basic  regrade  operation,  together  with  the  constraint 
that  the  document  being  regraded  is  available  to  the  window. 

(2)  The  window  is  unaltered  by  the  operation. 


_ _ regrade_f i le 

TRUSTED_PATH 

regrade_f i le 


tp_filing_systeh 


C  A  PAb  i  1  i  T» 
jour  nil  ltd 


file_cap7  e  available  (1) 

eWINDOW’  =  eWINDOW  (2  ) 


.  r  egr  ade_file_title 


TP_FIUNG_SYSTEn 


TRUSTED  PATH  .  ,  , 

—  c ipib i 1 i t  » 

regrade_f i le_t itle 


j  our  nil  ltd 


f i le_cap7  e  available  (1) 

eWINDDW’  =  eWINDOW  (2  ) 


(11  This  is  the  basic  regrade  operation,  together  with  the  constraint 
that  the  file  being  regraded  is  available  to  the  window. 

(2)  The  window  is  unaltered  by  the  operation. 

create_f i le. 


”TP_FILING_SYSTEf1 

TRUSTED  PATH 


create  f i le 


C  A  PAb  i  1  i  t  y 

j  our  ha  1  ltd 


doc_cap7  e  available  (1) 

available’  =  available  U  new_cap!  (2) 

- 1 


(1)  This  is  the  basic  operation  for  creating  files,  together  with  the 
constraint  that  the  document  capability  is  available  to  the  window. 
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(2)  After  the  operation  the  new  capability  is  available  to  the  window. 


add_doc_to_f i 


le 


TP_FILING_S'r'STEI1 


TRUSTED _PATH 

—  CiP<b i ! i ty 

add  doc  to  f lie  , ,  . 

—  —  —  j  our  nil 


■C  doc_cap7*  f i le_cap7  >  E  available  (1) 

eWINDOW  =  eUINDDU  (2  ) 


( 1 1  This  is  the  basic  operation*  together  with  the  constraint  that  both 
the  file  and  document  capabilities  are  available  to  the  window. 


(2)  The  window  is  unaltered  by  the  operation. 

Creating  a  document  involves  supplying  both  trusted  and  untrusted  capabilities. 
The  trusted  capabilities  will  be  for  other  documents  and  will  make  up  the 
capability  contents  of  the  new  document.  The  untrusted  capabilities  will  be  for 
other  objects  which  will  go  towards  making  up  the  textual  contents  of  the 
document.  The  only  important  part  of  the  untrusted  capabilities  as  far  as  this 
specification  is  concerned  is  the  high  water  mark  classification. 


_ create_document 


TP_P I L I NG_SYSTEM 


TRUSTED  JWH  . 

—  CIPlb * 1 i ty 

create_document  ,,  . 

—  jourrulltJ 

caps7  :  P  CAPABILITY 


caps7  e  available  (1) 

contents7  =  caps7  0  trusted_caps  (2  ) 

classification7  2  LU8-C  c  :  caps7  n  untrusted_caps  • 

hwm_class  which_group(  c  )  >  (3) 

available’  =  available  u  f  new_cap!  >  (4) 


(1)  All  the  supplied  capabilities  are  available  to  the  window. 

(2)  The  contents  capabilities  for  the  basic  operation  are  the  supplied 
trusted  capabilities. 

(31  The  classification  given  to  the  document  must  dominate  all  the  high 
water  mark  classifications  of  the  untrusted  capabilities  that  go 
towards  the  document  contents. 

(41  After  the  operation  the  new  capability  is  available  to  the  window. 

Reading  a  document*  looking  up  documents  in  the  cdr  or  filelist  and  listing  the 
contents  of  a  file  do  not  have  to  be  performed  from  the  trusted  path,  although 
they  could  be.  These  operations  will  make  further  capacities  available  to  the 
window.  Reading  documents  and  listing  the  contents  of  a  file  will  only  be 
permitted  if  the  user  is  cleared  to  do  so-  However  this  cannot  be  described 
until  the  section  13-2  when  users  have  been  further  specified- 
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find  document 


Fu.iNG_svsrEn 


^^eabbbility 

EHIGH  WATER  HARKS 


find  document 


j  our  1  i  ed 


(l ) 


window_id7  =  monitoring  ++ 

using’  =  using  U  {  doc_cap!  > 
class’  =  class 
group’  =  group 
eUINDOW’  =  eUINDOW 

(2  ) 

window  id?  *  monitoring  ** 

0UNTRU5TED’  =  eUNTRUSTED 
available’  =  available  u 

■C  doc_cap! 

(3  ) 

> 

find  filed  document  . .  . 

-  —  F  J  L  J  Itn 

^c»pab  1 1  i  tn 

3HIGH_WAT£R_MARKS 

(1  ) 

find  filed  document  ..  . 

—  —  j  our  nil  ltd 

window_id7  =  monitoring 

using’  =  using  U  f  doc_cap!  > 
class’  =  class 
group’  =  group 

8UIND0W’  =  eUINDOW 

(2  ) 

window  id7  *  monitoring  «-♦ 

eUNTRUSTED’  =  eUNTRUSTED 
available’  =  available  U 

{  doc_cap! 

(3) 

> 

-  « 

file  contents... _ 

-  ~  MLINb_ST5ltn 

i  1  i  ty 

EHIGHJJATERJ1ARKS 

file  contents .  . ,  , 

~  j  our  n« 1 1 md 

(1  ) 

window_id7  =  monitoring  *-* 
using’  =  using  U  caps! 
class'  =  class 
group’  =  group 
eUINDOW’  =  8WIND0U 

(2) 

window  id7  *  monitoring 

eUNTRUSTED’  =  eUNTRUSTED 

available'  =  available  U 

caps ! 

(3  ) 

(1)  Capabilities  for  documents  are  trusted  and  therefore  no  high  water 
marks  need  be  changed  as  a  result  of  this  operation. 

(2)  If  the  operation  is  performed  from  untrusted  software,  the 
capabilities  available  to  that  software  are  simply  increased  by  the 
new  capability  (or  capabilities).  The  monitoring  window  is 
unaffected- 
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(3)  If  the  operation  was  performed  in  a  trusted  path  window  the 
available  capabilities  are  simply  increased  by  the  new  capability 
(or  capabilities!  and  any  untrusted  software  in  the  display  is 
unaf  f  ected • 


.  1  i  st_cdrFIL1NG-SySTEn 

AOP  ,  ,  , 

C AP4b lilt* 

1 i st  cdr ,  ... 

—  j  our  n* 1 1 •<* 


eDISPLAY '  =  eDISPLAY  (1  ) 

_ _ J 

(1)  Because  windows  and  untrusted  software  are  modelled  by  the  set  of 
capabilities  available  to  them,  listing  the  cdr  does  alter  the 
display . 

Opening  a  document  will  reveal  further  (trusted!  capabilities.  There  a^e  no 
restrictions  as  to  where  this  operation  can  be  performed  as  documents  wll  only 
be  able  to  be  read  if  the  users  clearance  dominates  the  classification  (th  s 
will  be  specified  later  after  users  have  been  introduced,  see  section  14!. 

Reading  a  document  from  trusted  software  simply  makes  the  contents 
capabilities  available  to  the  window. 


, —  r  ead_documentTRUSTED^paTH 

AOP 


c  «  P«b  x  2  i  t  y 

r ead_document 


jour  nil  led 


window_id?  -C  p  :  programs  •  p .  mon  i  tor  i  ng  >  (1) 

doc^ap"7  e  available  (Z  ) 

available'  =  available  u  contents!  (3! 

eUNTRUSTED’  =  0UNTRUSTED 
eHIGHJJATERJIARKS'  =  8H1GH_WATER_P!ARK5 


(1&2)  The  window  is  not  running  any  untrusted  software,  and  the  document 
capability  is  available  to  this  window. 

(3)  The  capabilities  available  to  the  window  are  simply  increased  by  the 
contents  of  the  document.  No  untrusted  software  or  high  water 
marks  are  affected. 

Whenever  a  document  is  opened  by  untrusted  software,  the  high  water  mark  mav 
have  to  be  increased  to  take  account  of  the  classification  of  the  contents.  The 
following  diagrams  illustrate  this. 


5E 
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(l&Z)  The  window  is  running  the  untrusted  software »  and  the  document 
capability  is  available  to  the  untrusted  program. 


(3)  The  capabilities  available  to  the  untrusted  software  are  increased 
by  the  contents  of  the  document. 

(4)  No  capabilities  are  added  to  the  monitoring  window. 

(51  The  high  water  mark  for  the  untrusted  software  will  be  the  least 
upper  bound  of  the  initial  classification  and  that  for  the  document. 
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The  complete  operation  is  specified  to  be  either  of  the  above: 


read— documentFILiNG_sysTE|i  -  read_i documentTRUSTED^pfiTH 

v 

read_documentUNTRUSTED 

13.  Z  Filing  System  Operations  Performed  by  Users 

The  filing  system  operations  are  performed  by  users  in  one  of  the  windows  o-r 
their  display*  and  do  not  alter  cupboards*  passwords  or  clearances.  Certain  of 
these  operations  must  be  performed  by  specific  users. 

regrade_documentUSER  £  regr ade_documentTP  FILIN3  system  a  550 

re3rade_f  ileUS£R  £  r egr ade_f  i  leTP_FILING_sySTEn  a  SSD 

regrade.f  ile_titleUS£R  £  regrade_f  i  le_t  i  tleTP_FILING_SYSTEn  a  550 

create_documentuSER  £  cr  eate_documentTp_FILING_SY£TEn 

a  ®51Pfili(i#^ti(t)Bi|iUSER^STRTE 

cr eate_ f  i  leUSER  £  create_f  i  leTp^F.IL]NG^sysTEn  a  CLERK 

add_doc_to_f  i  leUSER  £  add_doc_to_f  i  leTp^FILING^£ysTEn 

A  <&^filin9_,yst*»USER_STATE 

f  i  nd_documentUSER  £  f  i  nd_documentF  1L  ING_sySTEn  a  $|5PflliBS_til,te„>USEB_sTeiE 
f  i  nd_f  i  led_documentUS£R  £  f  i  nd_f  i  led_documentFILING  SYSTEr1 

A  ®^Pf,lin9_«IISt*l»USER_STOTE 

llSt_cdrusER  £  1  I  St_cdrFILIN5-SYSTEr1  A  ,  I  j  ns  _,9,  t«*USER_STATE 


( 1 )  In  order  to  read  a  document*  the  users  clearance  must  dominate 
the  classification  of  the  document. 
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f  i  le_contentsUS£R _ 

i  n*_«y«  t««US£R_ST(JTE 

f,le_contentsF1LING_sysTEf1 


which_user(  caused_by?  ). clearance  2  file. classification  (1) 
where 

file  ran  which_file  |  title  =  title7 


(1)  In  order  to  list  the  contents  of  a  file,  the  users  clearance  must 
dominate  the  file  classification. 
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14.1  Cupboard  Operations  in  a  Display 

The  basic  operations  on  a  cupboard,  see  section  6-3,  will  be  performed  m  s 
display . 

The  actions  of  the  find  operation  depend  on  whether  the  operation  is  invoked 
from  trusted  or  untrusted  software  and  the  trustworthiness  of  the  particular 
capability.  There  are  four  cases,  which  are  illustrated  and  specified  below. 


Figure  9a:  A  trusted  path  window  prior  to  looking  up  an  untrusted 
capability  in  the  cupboard. 


Figure  9b:  Trusted  path  window  after  adding  an  untrusted  capability 
from  the  cupboard. 


(1)  A  new  related  group  object  is  created  for  this  capability  and  given 
the  high  water  mark  classification  taken  from  the  cupboard.  The 
new  capability  is  made  available  to  the  window.  No  untrusted 
software  or  other  windows  are  affected. 


G0 


Cupboard  Operations 


lUPBOARD 
one  £ 


Restricted 


Figure  10a:  The  situation  priior  to  untrusted  software  looking  up  an 
untrusted  capability  in  the  cupboard. 


.CUPBOARD, 
one  H 

two  H 


three 

Secret 


Secret 


Figure  10b:  After  adding  an  untrusted  capability  from  the  cupboard. 


_f  indu - 

P  *  ndu n t pus  t 


eUlINDDU  ’  =  eUINDOU 

using’  =  using  U  -C  cap!  >  (1) 

known’  =  known 
group’  =  group 

class'  =  show  hwm_class’(  group  ) 

which _group’  =  which _group  U  <  cap!  ►*  group  >  (Z) 

hwm_class'  =  hwm_class  •  {  group  «  (  hwm_class(  group  ) 

lub 

class!  )  > 


(1)  The  new  capability  is  added  to  the  set  that  the  untrusted  software 
is  using.  The  monitoring  window  is  unaffected. 

(Z)  The  new  capability  is  added  to  the  related  group  for  that  software, 
and  the  high  water  mark  is  increased  as  appropriate.  No  other  high 
water  marks  or  groups  are  affected. 
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Whenever  trusted  capabilities  are  taken  from  the  cupboard  no  high  water  ms^s 
or  related  groups  need  be  altered- 


(1)  The  capability  from  the  cupboard  is  made  available  to  the  window, 
and  no  high  water  marks  or  untrusted  software  change. 


(11  The  capability  from  the  cupboard  is  added  to  those  available  to  the 
software.  The  monitoring  window  and  high  water  marks  are 
unaf  f  ected . 

The  complete  find  operation  is  one  of  the  four  cases. 

findoisPLAv  ~  findu.P  v  f,ndttp  v  findu  v  find, 

It  would  be  a  signalling  channel  if  untrusted  software  could  store  capabilities  n 
the  cupboard,  so  this  operation  must  be  performed  from  the  trusted  path.  No 
untrusted  software  will  be  affected  by  storing  capabilities,  except  in  that  the 
capability  can  now  be  found  by  software  with  access  to  the  same  cupboard- 


( 1 1  In  order  to  remove  the  problem  of  the  related  sets  (see  section 
5.2)  whenever  untrusted  capabilities  are  stored,  what  is  in  fact 
stored  is  a  capability  to  a  new  object  with  a  copy  of  the  original’s 
contents • 
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(2)  The  capability  bems  kept  must  be  one  of  those  available  to  the 
window . 

(3)  The  classification  that  is  kept  with  untrusted  capabilities  must  be 
correct . 


Cl)  The  capability  bein9  kept  must  be  one  of  those  available  to  the 
window . 

The  complete  operation  is  either  case- 

keePoispLAY  *  keepu  v  keept 


The  Cupboard  operations  will  be  performed  by  any  of  the  users  of  Sercus  in  one 
of  the  windows  of  their  display. 


^'nc*USER  &  ^mC*OISPLAY  A  ®^^cupko»fiUSER_STATE 
keePUSER  -  keePDISPLRY  A  u pk  opr iUSER.ST ATE 
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15.1  hail  Operations  Performed  in  a  Display 

The  mail  operations  will  be  performed  in  a  window  of  a  display.  No  high  wate' 
marks  or  untrusted  software  are  altered.  In  order  to  prevent  untrustec 
software  using  messages  as  a  signalling  channel,  the  message  operations  must 
be  performed  from  the  trusted  path. 


(1)  The  capabilities  making  up  the  message  must  all  be  available  to  the 
window . 


(2)  The  window  is  not  altered  by  the  operation. 


(1)  Opening  a  message  will  make  its  capabilities  available  to  the  window. 
These  capabilities  are  all  trusted,  and  therefore  no  high  water 
marks  or  related  groups  need  change- 

15.  Z  hail  Operations  Performed  by  Users 

The  mail  operations  may  be  performed  by  any  user  of  Sercus.  As  for  the  filing 
system  operations,  only  the  capabilities  available  to  the  display  of  the 
particular  user  may  alter.  The  password,  clearance  and  cupboard  cannot 
change.  * 


(1)  The  user  identifier  for  the  sender  of  the  message  will  be  correct. 

(2)  Messages  may  only  be  sent  to  valid  users- 


6*1 


ha i 1  Oper at i ons 


open_next_messageUSER  _ 

il »  t«»USER_STATE 

open_next_messageOISPLflY 


me7  =  caused_by? 


Cl)  A  message  may  only  be  opened  if  the  message  is  destined  for  the 
owner  of  the  window. 


fla  1 1  Operat  i  ons 
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IB.  Promoting  the  Operations  Involving  a  Display 


The  operations  that  alter  the  windows  and  software  in  a  display  will  also  be 
initiated  from  one  of  the  windows  in  the  display.  The  following  schemas  define 
this  situation. 


raopiijpl() 

ADISPLAY 


window_id7  :  1*1 1 D 

AUINDOU 

AUNTRUSTED 


window_id7  e  windows 

GUJINDDuI  =  wh  i  ch_w  i  ndow (  window_id'7  ) 
eUINDOU’  =  wh i ch_w i ndow 1 (  window_id7  ) 


As  for  the  AOP  ,  schema  the  particular  display  and  window 

UPlbihty 

that  the  operation  is  performed  from  are  defined.  This  schema  does 
not  define  how  the  untrusted  software  and  windows  are  altered  as 
this  is  defined  in  the  basic  operation  schemas- 

_ TRUSTED_FATH  ,  _ _ 

—  display  ■ 

A0PdiSPUy 

EHIGHJ4ATERJ1ARKS 


window_id'7  4  *C  p  :  programs  •  p. monitoring  > 

_ _ _ „ _ _ _ ) 

The  operations  upon  a  display  are  performed  by  a  user.  Users  may  only  alter 
their  own  display,  and  no  others.  No  passwords,  clearances  or  cupboards  w  11 
be  affected  by  the  operations  upon  the  display. 

—  ®^Pdi«  pUyUSER.STATE  - 1 

A^PdnpUy 

AJOURNALLED _U5ER_5TATE 
EJOURNALJJSERS 

caused_by?  :  UID 


my_d i splay ( 

caused_by7  )  = 

eDISPLAY 

my_d i splay’ 

=  my_di splay  e 

■C  causedjoy7  «  9DI5PLAY’  > 

( 1  i 

wh i ch_user  ’ 

=  which_user 

C2  ) 

logged_i n  ’ 

=  logged_m 

(3  ) 

(1)  The  display  for  the  particular  user  will  be  altered  by  operations, 
and  no  others. 

C 28.3 )  Operations  upon  the  display  do  not  alter  the  password,  clearance 
or  cupboard  of  any  users,  nor  the  set  of  logged  in  users. 


EG 


17.  The  Operations  upon  the  Display  nf  a  User 


17.1  Display  Operations  performed  from  a  Display 


The  operations  on  a  display  described  in  section  5.6  will  be  initiated  from  one  of 
the  windows  of  a  display.  These  schemas  combine  the  basic  operation  with  the 
schema  that  defines  operations  to  take  place  in  a  display,  and  ties  the 
components  t09ether. 


_ create_w i ndow 


OISPLAY 


TRUSTED  PATH  , 

—  display 

create  window, 

—  b if iC_op 


empty_w i ndow  =  8UIND0U' 


i _ run_un trusted 

TRUSTED  PATH, 


DISPLAY 


a  x  s  p l Ay 

run  untrusted, 

—  b«SlC_OP 


r_complete_untrustedOISPL((Y  _ 

^^iipUii 

complete  untrusted, 

—  bit iC_OP 


window_id7  =  pr og7 . mon i tor i ng  (1) 
SUNTRUSTED  =  prog7 


g  i  ve_to  _un trust ed0ISPLflY 

CiQP .  , 

a i s  play 

give  to_untrusted, 

—  1  C  __  0  F 


window_id7  =  w i d7 
0UNTRUSTED  =  prog7 
SUNTRUSTED’  =  prog! 


(1  1 


take  from  untrusted 


display 


®an  pin 

take  from  untrusted, 

—  —  basic^o 


window_id7  =  w i d7 
SUNTRUSTED  =  prog7 
eUINDDU'  =  window’ 


(1  ) 


til  This  ties  up  the  window  performing  the  operations  with  the  window 
from  the  basic  operation  schema. 


17-2  Display  Operations  performed  by  Users 


Users  may  perform  the  operations  to  alter  their  display,  such  as  creating 
windows  and  running  untrusted  software.  These  operations  are  not  restricted  to 
users  with  certain  roles,  however  a  user  can  only  affect  their  own  display- 


g  i  ve_to_untrustedUSER  ft  g  i  ve_to_untrustedDISPLSy  A  $0P4ltpl„ 
take_from_untrustedUSER  ft  take_f r  om_untr  ustedD[SpLflyA  (JiOP 
create_w,ndowUSER  ft  cr  eate_w  ,  ndowOISPLsy  A  ®0P-ilM41(USER_8T*TE 
run_untrustedUSER  ft  run_untrusted0ISPLfty  a  plt„USER_ST0TE 

complete_ur, trust edUSCR  ft  complete_untrustedOISPLRy  a  4>0P4 


USER _S TATE 

pl*yUSER_STATE 


UsiUSER.STATE 
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18.  The  Operations  upon  Users 


18-1  User  Operations  performed  in  a  Display 

With  the  exception  of  logsing  in.  the  operations  on  users  will  be  requested  from 
one  of  the  windows  of  a  display-  811  these  operations  must  be  performed  fro— 
the  trusted  path-  No  capabilities  are  involved  in  these  operations  and  hence 
there  will  be  no  change  to  the  capabilities  available  to  the  window. 


create_user0ISPLflY  £  create_user jour Mll#a  a  TRUSTED-PATH,^  pUy 


change_password0[SPLfly  £  change_passwordjournil  lea  a  TRUBTEDJWm^^^ 


a  “WINDOW 

a  SWIND3W 


change_clearanceDISPLay  £  change_clear ancej our M d 


a  TRUSTED  PATH  ,  a  EWINDGW 

~  display 


iog-Outo^pLBv  lo9_outjeurn4U#a  A  TRUSTED_PATHdispUu  a 


rWINDDw 


18-2  Operations  upon  Users  performed  by  the  Users 


The  operations  on  the  users  of  Sercus  will  be  performed  by  the  users  in  one  cf 
the  windows  of  their  display.  Creating  users  and  changing  clearances  must  ce 
performed  by  a  system  security  officer. 


create_userUSER  £  cr eate_use-DISPLftY  a  SSO 
change_clearanceUS£R  £  change_clearance[>ISPLSy  a  SSD 


—  USER  - 

1 

puuuser_stcte 

1 D  q  Out 

DISPLAY 

u i d7  =  caused_by7 

(  1  ) 

.  change_passwor d 


USER 


a  .  i Pl *nUSER_STOTE 

change  _password 


DISPLOY 


u  i  d7  =  caused_by7 


(  1  ) 


(11  Users  may  only  change  their  own  password  and  log  themselves  out. 

Note  that  logging  in  is  not  specified  as  unlike  all  the  other 
operations,  it  is  not  performed  by  a  logged  in  user  in  one  of  the 
windows  of  their  display. 


19.  Sereus  -  the  Complete  System 


The  complete  system  far  Sereus  is  the  journalled  filing  system/  journalled 
users/  the  mail  system  and  anonymous  objects,  together  w'th  constraints  to  tie 
them  together.  This  section  puts  all  the  components  specified  in  the  preceeding 
sections  together,  and  defines  the  operations  to  take  place  in  this  state. 

SERCUS _ _ 

J0URNALLED_FILING_5YSTEP1 

THE_AN0NS 

JOURNALLED_USER_STATE 

HAIL 


U  u  :  ran  which_user  .  (1  ) 

ran(  u • cupboard • name  )  E  exist 

-C  w  :  wh i ch_w i ndow C  u. windows  )  •  w. available  3-  £  exist 
■C  p  :  u. programs  •  p. using  }  £  exist 

where 

exist  =  dom  which_doc  U  dom  which_file  U  dom  which_anon 


{  m 

:  ran  ma i 1 

.  m. message  >  £  dom 

wh  i 

n 

zr 

'a. 

o 

n 

(2  1 

ran 

mail  £  dom 

wh i ch_user 

(3  1 

{  m 

:  dom  ma i 1 

•  m.from  }  £  dom  wh 

i  ch_ 

user 

(4  1 

(11  All  the  trusted  capabilities  in  the  cupboards,  windows  and  software 
must  be  for  existing  documents  and  files.  and  untrusted 
capabilities  must  be  for  existing  anonymous  objects. 

(21  Messages  can  only  contain  capabilities  for  existing  documents. 

(31  Messages  may  only  be  sent  to  legal  users. 

(41  Only  legal  users  may  send  messages. 

ASERCUS  £  (  SERCUS’  ;  5ERCUS  1 

ESERCUS  £  [  ASERCU5  I  eSERCUS’  =  0SERCU5  ] 

19-1  Initial  State 

The  initial  state  of  Sereus  is  a  single  user,  who  will  be  a  system  security 
officer-  There  will  hence  be  a  single  journal  on  the  user  state.  There  will  be  no 
documents  or  files,  and  consequently  no  journals  for  other  objects,  no  mail 
messages  or  anyone  loggedjn. 
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INITIAL_5TATE 

A5ERCUS 


which_doc’  =  -O 
wh i ch_f ile’  =  O 
wh i ch_anon ’  =  O 
mail’  =  O 
lo9ged_in’  =  O 

tt  dom  which_user’  =  1 

d  u  :  ran  which_user'  •  u- cupboard  =  O 

u- clearance  2  sso 

«  journal _users’  =  1 

dom  journal_u5ers’  =  dom  which_user’ 


19-2  Operations  on  the  Complete  State 

Piling  system  operations: 

re9rade_dccument  £  regr ade_documentUSER  a  EMAIL  a  ETHE_AN0N5 
regrade_file  £  regr  ade_f  i  leUSER  a  EMAIL  a  ETHE_AN3N5 
r egrade_f i le_t i t le  £  r  egr  ade_f  i  le_t  1 1  leUSER  a  EMAIL  a  ETHE_AN0\5 
cr eate_document  £  cr eate_documentUSER  a  EMAIL  a  ETHE_ANDNS 
create_file  £  create_f  i  leysER  A  EMAIL  a  ETHE_ANDN5 
add_doc_to_f i le  £  add_doc_to_f  i  leUSER  a  EMAIL  a  ETHE_ANDN5 
f i nd_document  £  f i nd_documentUS£R  a  EMAIL  a  ETHE_ANCNS 

f  \  nd _ f  i  led _ document  £  f  i  nd_f  i  led_documentUSER  a  EMAIL  a  ETHE_ANuNS 

list_cdr  £  1 1  st_cdr a  E5ERCU5 

f i le contents  £  f i le_cantentsUSER  a  EMAIL  a  ETHE_AN0NS 

read_document  £  read_.documentUSER  a  EMAIL  a  ETHE_AN0NS 

find  £  fmdUSER  a  EMAIL  a  EJOURNALLED_FILIND_SYSTEM 
keep  £  keepUSER  A  EMAIL  a  EJ0URNALLED_FILING_SY5TEM 

flail  operations: 

send_message  fi  send_messa9eUSER  a  ETHE_ANONS 

a  EJDURNALLED_FILING_5Y5TEM 

open_next_message  £  open_next_messageUSER  a  ETHE_ANDNS 

a  EJOURNALLED_FILING_SYSTE 

Display  operations: 

create_w i ndow  fi  cr  eate_w  i  ndowu£ER  a  EMAIL  a  ETHE_AN0NS 

a  EJDURNALLED_F1L1NG_SYS7EM 
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run_untrusted  £  r un_untrustedUSER  A  EMAIL  a  ETHE_ANONS 

a  EJOURNALLED_FILING_SYSTEM 

91 ve_to_untrusted  £  9 i ve_to_untrustedUSER  a  EMAIL  A  ETHE_ANONS 

a  EJDURNALLED__FILING_SYSTEM 

take_from_un trusted  £  take_from_untrustedUSER  a  EMAIL  A  ETH£_ANQN5 

a  EJ0URNALLED_FILING_5Y5TEM 

comp I ete_un trusted  £  complete_untrustedUSER  A  EMAIL  A  ETHE_AN0N3 

a  EJDURNALLED_FILING_SY5TEM 

User  operations: 

create_user  £  create_userUSER  A  EMAIL  a  EJOURNALLED _FILING_5YSTEM 

a  ETHE_ANDN5 

log_out  £  log_outUSER  A  “MAIL  A  EJQURNALLED_FILING_SYSTEM 

a  ETHE_ANQN5 

change_clearance  £  change_clearanceUSER  A  EMAIL  A  “THE_AN0NS 

a  ejdurnalled_filing_system 

change_password  £  change_passwor dUSER  a  EMAIL  A  ETHE_ANONS 

a  SJDURNALLED_FILING_5YSTEM 

log_in  £  lo9_inj#upn4lU4  A  HMAIL  A  EJ0URNALLED_FILING_5Y5TEM 

a  ETHE_ANQNS 


20.  Summary 


This  document  has  formally  specified  the  requirements  for  an  example  secure 
system.  The  first  part  described  all  the  components  that  were  required  in  the 
final  system  and  defined  the  simple  operations  upon  these-  The  next  pa^t 
defined  how  these  components  were  to  be  combined  and  showed  how  the 
operations  on  the  various  compoents  were  related  to  the  others.  Ths 
structuring  of  the  specification  makes  it  much  easier  to  read  and  highlights  the 
dependencies  and  constraints  it  will  be  necessary  to  enforce  in  the 
implementation.  The  actual  set  of  operations  that  have  been  defined  is  farl-. 
limited-  However,  enough  operations  have  been  specified  to  provide  a  useable 
system  and  to  illustrate  all  the  important  areas. 
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